Hi there.
I'm Nathan Lamont, a full stack developer who architects and leads development on enterprise web sites, web-based tools, and native mobile apps. I focus on using UI/UX to inform technological needs, and always seek joy and simplicity over complexity.
Below, please find some of my UI explorations.
For many years, I’ve been (heathily) obsessed with the potential for app-like sites to leverage their improved page-to-page navigation by providing contextual animation. When a link to a page shares an element with the page itself — say, an image — it can make sense to animate the image from the position on the page the user is navigating from to its new position on the page the user is navigating to.
I’m not alone. Chrome recently released an experimental feature called “View Transitions” that facilitates this, and there are indications that Firefox and Safari will follow suit, but… when?
In the meantime, I created a generalized Vue solution that works in all browsers today. It allows a developer to simply denote an element as a potentially “shared” element. It works with multiple elements simultaneously transitioning, and with images that occupy the same role but have different aspect ratios.
A way to have your sticky header on desktop without crushing the souls of your users. They get predictable pagination and all the vertical space their window allows, and you get to keep your brand and navigation accessible all the time, just like you want.
Hierarchical information — like org charts, career paths, or site maps — can be difficult to represent flexibly and robustly, especially when making concessions to the cramped width of a mobile device.
This exploration offers a solution that can grow horizontally and vertically to make navigating a tree with even hundreds of leaves reasonable. When the user clicks a leaf, its ancestor leafs align above it to make its position in the hierarchy easily discoverable.
One of the annoyances for a user when dealing with paged data on websites is the shifting of the position of controls as the height of the data changes. An inelegant solution to this is to place the pagination controls at the top, where they are less likely to shift — but then, if the page of data requires the user to scroll to the bottom, they must scroll back up to the top to get to the next page. So, the pagination controls might be repeated at the top and the bottom.
App-like sites are perflectly suited to solve this problem. My exploration, using a site with 140 pages of data, offers two novel improvements: