Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Retrofitting Zooming UI To Legacy Websites: An Impossible Task?

It’s well known that, in the ’80s, Microsoft and Apple made the graphical user interface (GUI), the dominant interface on desktop computers. What’s less known is that the GUI, whose navigation is based on pages and links, is not the only possible interface. And we know that finding our way in a modern GUI, whether for a website or application, is not always easy.

One problem is of design, meaning that an interface could simply be poorly designed. But a different problem may very well be the way our brains are wired; even well-designed interfaces can be difficult to navigate and use1.

Further Reading on SmashingMag:

In this article, we will investigate an alternative to the classic “pages and links” paradigm, a model dubbed “zoom navigation.” We will try to answer the question, If zoom navigation is better, then why is it so uncommon? At the end of the article, we will introduce some prototypes and discuss their technical implementations.

Imagine a wall in your office covered with sticky notes, images and labels. These pieces are grouped together by proximity. From a distance, you have a general overview and understand the groupings. If the sticky-note wall is new to you, you might start to explore it. You might read the big labels from a distance or walk closer to the wall to see more details. Now, imagine that the wall is not new to you, and you’re searching for specific information. You know you put that information on a green sticky, and you might remember that it was close to a red cross mark. So, you walk closer to the right side of the wall, and there it is: the sticky you were looking for!

ZUI-01-opt6

Zooming in to see more details (View large version7)

This physical experience is similar to the digital experience we have each time we use Google Maps. Starting somewhere on a map, you might zoom in:

ZUI-02-opt8

Zooming in on Google Maps (View large version9)

As in the sticky-note example, you can now see details you couldn’t see before. And, of course, you may have zoomed out instead of in when starting off:

ZUI-03-opt10

Zooming out on Google Maps (View large version11)

You might zoom in or out many times to find what you’re looking for. There are no links, no pages and no scrolling bars, just this huge canvas where you can see things from a distance, as if on an airplane, or close up.

Now imagine you’re in a room with many doors. The doors have labels. Some make sense, others don’t. You can’t see what’s behind a door. And when you walk into a room, you can’t see the room you’ve just left. After having walked through many doors, you don’t have a map of the system of rooms; you have to keep track of the relationships between rooms in your head. This sounds like a description of a maze right?

ZUI-04-opt12

A maze (View large version13)

The digital counterpart of this is websites as we know them. The rooms of the maze are a website’s pages, and the maze’s labelled doors are the navigation menu, with sometimes cryptic links.

ZUI-05-opt14

Websites are like mazes (View large version15)

Google Maps is arguably the best-known example of an interface whose navigation is based on a zooming mechanism. But it’s not the only one. Much design software works like this. Take Sketch, where it’s possible to zoom in and out on an infinite canvas.[116]

ZUI-06-opt-preview17

Infinite canvas in Sketch (View large version18)

Even though Google Maps is well known and certain design applications use zooming navigation, there are not many more examples. Conventional navigation is made of pages and links. Is this because people dislike zooming in and out? Let’s quickly examine this hypothesis. Google Maps is one of the most widespread apps. It’s ranked number 6 in Nielsen’s list of top smartphone apps19 of 2015 (at number 10 is Apple Maps, which has similar zooming navigation). Sketch is an award-winning Mac app that’s been very successful in the last couple of years.

These facts alone don’t prove that zooming navigation is much appreciated by these users. Surely many other factors account for users’ love for this applications, but it’s hard to believe that people dislike this kind of navigation either, because it is so integral to both applications.

If it’s not true that people dislike this kind of navigation, then is it true that people like navigation based on pages and links more? Upon examination, this doesn’t seems to be the case either. Most articles by Nielsen Norman Group about usability in one way or another are about standard links navigation.

Another hypothesis is that zooming navigation isn’t technically easy to implement. While we can agree that many of the best developers out there are working on Google Maps, and we might also agree that the small team of software engineers working on Sketch consists of very gifted people, it seems unrealistic that they are the only ones.

Let’s try to better understand the features of zooming navigation.

Jef Raskin’s Zooming Navigation Idea Link

In 2000, human-computer interaction expert Jef Raskin wrote about Zoomworld in his book The Humane Interface20 (see paragraphs 6.1 and 6.2). Zoomworld is an interface concept based on a zooming navigation paradigm similar to the ones we’ve just reviewed.

Raskin believed that zooming navigation is superior to the maze-like standard navigation model because of how we humans have evolved: We are good at knowing where we are in relation to things and where things are relative to each other. We are also good at recognizing marks. We are not good at finding our way in a maze.

Imagine if we could fly above a maze, being able to see the entire layout and getting a quick sense of where things are, diving to zoom in on a detail and climbing to zoom out. Zooming navigation might allow for just that, exploiting our cognitive strengths and easing our brain’s workload.

Raskin introduces the idea of zooming navigation in the design of an intensive care unit (ICU). As a first step, he shows a user zooming into room 132 Davis:

ZUI-07-opt-preview21

Plan of an intensive care unit (View large version22)

On the left above, we have a view of the entire ICU. We are not able to read everything; we get a sense of the location of rooms, and we might be able to read the names of the rooms (at least in Raskin’s original screenshot). We also understand that the ICU is not the only unit.

Again, once in room 132 Davis, we can’t see every detail. For example, we can’t read any content in the “Flowsheet,” “System” or “Lines” section. We can just read the titles and see the shapes of the sections (for example, a table, a list, a picture). To see the details of the flowsheet, we would have to zoom in:

ZUI-08-opt-preview23

Plan of an intensive care unit (View large version24)

We saw the same with Google Maps: When we zoomed in, we saw new roads, new rivers, new labels.

Is that confusing for the user? Will they lose their sense of location and where things are? They probably won’t because of the mind’s ability to close the gap between the room view and the flowchart view. See the white gutter between room 132 and the flowsheet above? That’s closed by our mind. The easier that gutter is to close and the better the design and the animation of the zoom interaction, the less the user will feel confused. This ability to close gaps with our imagination is called “closure.” [225]

At any time, we can zoom out to view part of the hospital, whereupon we would see that the ICU is located on floor 1:

ZUI-09-opt-preview26

Plan of an intensive care unit (View large version27)

Again, we can’t read everything. Could this be the real problem, the crucial weak point of the whole zooming concept and the one preventing its widespread adoption? We could make a few observations that would suggest this feature is actually more of an advantage than a weakness.

First, we don’t read everything, even when we’re able to. A ton of usability literature [328] shows us that we don’t read websites, but rather scan them. According to usability guru Steve Krug, people “glance at each new page, scan some of the text…. There are almost always large parts of the page that they don’t even look at.”

Secondly, our aim when viewing things from a distance, as if on an airplane, is to get the big picture, to grasp positions and marks. The zoomed-out view supports our need to make sense of the context.

If context were not essential to us, we wouldn’t have introductions and tables of contents in books; we wouldn’t ask about the neighborhood before looking into buying a house; and we wouldn’t listen for a few moments before jumping into a conversation between friends we’ve just approached. The examples in favor of understanding context before details are countless.

Context plays a role in responsive design29. We’ll return to this later when we explore zooming navigation in a multi-device world. Let’s get back to Raskin’s hospital. He states that tests prove that this interface is easier for nurses to learn than any other alternative. [430]

From this example, we can appreciate the main points that distinguish zooming navigation from links navigation: There are no links, no pages and no page-scrolling bars; we can zoom in and out multiple times; and, finally, the interface design should support closure.

Let’s check some modern examples to see how they compare with Raskin’s model.

Hybrid Interface Link

ZUI-10-opt-preview31

(View large version32)

Above on the left is the desktop view of the home page of Work & Co33. On the right is where we “land” when we click the white rectangle in the top left of the home page.

Closure is easy: There are no new elements in the zoomed-in state. And the zoom animation is exactly what we would expect from a zoom interaction. There are pages, and we can scroll them — we might have expected that, because we come from a long history of scrollable interfaces — but that’s not part of Raskin’s zooming model.

Another example is the website of Joni Korpi34. He is (another) pioneer who was inspired by Raskin’s ideas.

ZUI-11-opt-preview35

(View large version36)

Above left is his home page (desktop view). On the right is the result of clicking the top-left region, labelled “Modeless Zoomable UI.”

We need some mental work to close the gutter here. There’s no hint on the home page of the text on the “Modeless” page. And the full animation is not a pure scaling up; it’s something different that doesn’t faithfully support the zoom mechanism. [537]

Also, notice that there’s just one zooming level and that we can move about the website with links. Like the previous example, this is a hybrid interface with features of both worlds: Raskin’s and the “pages and links” world.

Another pioneer is David DeSandro38, who provides a technical explanation39 of the process of creating the website for Beercamp 2011:

ZUI-12-opt-preview40

(View large version41)

I can appreciate the multi-level zooming navigation here, whose mechanics are delegated to the horizontal navigation bar and the scrolling down arrow. What I like about DeSandro’s implementation is the unreadable “mess” at the center of the page. It seems like a mistake before we realize we can zoom in. This is the essence of zooming: the distinction between the forest and a single tree. What users don’t like is having to scroll in two different ways. The introduction of a new mode42 becomes confusing.

According to Raskin, whenever we add to pure zooming navigation some of what he calls “our old habits,” such as links or scrolling, we defeat the purpose of the paradigm, which is to exploit our innate cognitive skills.

Granted, when we use Korpi’s interface, we see many inconsistencies with the original model. And even if we think that there’s something fundamentally true in Raskin’s ideas, we also think that there might be many possibilities for extending those ideas. [643] That’s why I think that Joni Korpi’s work is promising and valuable.

Going back to our question of why zooming is not more widespread, in our investigation till now, we couldn’t find any good reason why it hasn’t been adopted. Korpi wrote to us saying that he found that designing zooming interaction itself (i.e. how the user actually zooms in and out) to be a challenge. Is the actual interaction a possible weakness of the zooming idea and the answer to our question? Before diving into the interaction problem, let’s go back to 2007, when this idea had its best chance to exit the darkness.

Multi-Device World Link

Raskin presented the idea of zooming navigation for a fixed-width interface. He wasn’t concerned with multi-device design. Google Maps works seamlessly on phones and desktop computers. It seems that zooming is almost by default the appropriate method of browsing a single interface on both big and small screens. Did we ignore the advantages of zooming in this new multi-device world? Let’s investigate.

When the iPhone appeared in 2007, its “browsing interaction was clumsy44.” Websites designed for much bigger screens were impossible to read on the phone. We needed to pinch and zoom to make a portion of the screen big enough to be readable, and then scroll or drag to move around.

Ethan Marcotte proposed a solution45: responsive design, which is now the standard. The benefits were immediately clear. We could see text and images without having to pinch and zoom.

Marcotte tells us that he attacked the problem starting from the issue of the relative width of elements; then, he attacked the problem of image width, and then the problem of breaking points in the layout. What’s interesting is not the remarkable way he solved the technical problems he faced, but that the implicit goal of his work has always been to enable the user to see and read everything on every screen, big and small.

What if we were to admit that not being able to read everything is not really a cost if we can see and read the main pieces of content? To better understand this point, compare the following two views of the same page, taken from Nielsen Norman Group’s website46:

ZUI-13-opt-preview47

(View large version48)

On the left, we can’t read anything. We can make out the structure, but that’s probably not enough to understand the context (i.e. what the website is about and what options are available). Also, we can’t tell whether we’d be interested in the main content (i.e. the article’s text).

We’d have to zoom in to know. By contrast, on the right, we can see the name of the website, the link labels in the main horizontal navigation, the section titles in the secondary vertical navigation, and the title of the article. That’s enough to grasp the general context of the website and to decide whether we are interested.

By questioning Marcotte’s implicit hypothesis and including some unreadable interface parts, we have two advantages over a responsive design. The first advantage is that users would be able to grasp the context quickly without any interaction. That’s not a minor point. On a responsive website, you often have to at least scroll or click on a hidden menu to grasp the context. The second advantage is that we don’t have to change the layout at breaking points; it’s just a different zoom level, and it may or may not include new parts of the canvas. This means we deliver the same experience on all devices. That’s not the case with responsive websites, which by definition have to change the position of content on different devices to keep the content at a readable size.

The Interaction Problem Link

Back to an important problem with zoom navigation: How should one zoom in and out? There’s no convention. This is perhaps a problem, but also an opportunity. Raskin lived in a desktop world, and he talked about an ad hoc mouse. Now we have to think about this interaction for a multi-device world.

This is Korpi’s take:

Even if we ignore the really hard cases, like screen readers [749] (and we shouldn’t), we can safely expect that our users can tap, tap and hold, tap and drag, and scroll vertically. That’s a very narrow set of interactions to design around, a stark contrast to where you might usually see ZUIs or other complex UIs: desktop applications with their keyboards and mice/trackpads, and video games with their controllers.

Designing with this limited palette of interactions tends to lead to UIs cluttered with hovering buttons and a prevalence of modes — something Raskin and other UI pioneers strongly advocate against. It’s a massive challenge and likely contributes to why ZUIs haven’t seen much use.

Add to this consideration the different navigation models of devices. For example, we can use the “back” button on an Android device to zoom out, but we can’t on an iPhone.

While these problems might explain why zoom navigation has not succeeded in a mobile world, they don’t explain why the idea did not succeed between 2000 (when Raskin published his ideas) and 2007 (when Apple created the iPhone).

I am optimistic. History has taught us that good ideas sometimes go unnoticed for a long time.

Retrofitting Link

If we take a fixed-width website and open the developer tools in any browser, we can:

  • add the viewport meta tag to set the content’s width and initial scale;
  • change the pixel values to percentages;
  • add some media queries to see how fast we can turn a good-enough website into a better experience on mobile.

This is a testament to how clever responsive design is.

Ben Callahan50 describes this approach as “finding the fastest and lowest-risk approach to creating a better experience on an existing site for users on any device screen” or, in a word, “retrofitting51.”

Let’s explore a possible zooming retrofit of Nielsen Norman Group’s website (shown above). We’ve already started the retrofit by increasing the font size of the most important text (see the right side of the image). We can’t read the links in the sidebar or the main article. In this example, the page is basically made up of three regions (see the layout below). To read the main content, we would zoom into the region (by tapping anywhere in the region). We can do that now with a double-tap, but we’ll get scroll bars. [852]

ZUI-14-opt53

(View large version54)

Once you’re in a region, you can move between regions by swiping. Check it on mobile: Zoom in on a single scene with a single tap, and move to the next by swiping. Then, zoom out with another single tap. This makes for a modal interaction gesture that might be improved by using the “back” button to zoom out.

This is a hybrid interface with pages, links, scrolling and specific use of the zoom interaction. It’s worth testing with users because it preserves the context better than a responsive solution, and it takes advantage of the zooming capability to exploit our brain’s strengths.

Retrofitting: A Very Early Technical Exploration Link

Retrofitting an old website might be technically possible by using CSS transformations and JavaScript. However, as with most things, it will depend a lot on the situation. For a legacy website, a complete rewrite might be a much better investment than trying to patch on more stuff. For another website, the latter might be a better option.

So, for a moment, let’s imagine that we are trying to attach zooming powers to a legacy website. How would we start? Following a basic prototype55 (or see the accompanying video56 if the prototype doesn’t work on your device), we will briefly describe what one potential approach looks like. Try double-tapping the sidebar on your smartphone and swipe to the right to see how the zooming effect works.

Please keep in mind that we are by no means stating that this approach is the right solution. It’s just an idea of how it could work.

Avoiding a long-drawn technical explanation, we can roughly summarize the approach taken with the prototype like so:

  1. Apply classes to regions of the legacy website that you want to make zoomable.
  2. Scale up headlines a bit using CSS and media queries on the device sizes you wish to target.
  3. Use jQuery (or vanilla JavaScript) to loop through and map all of the regions that you defined earlier with classes, and save them to an array for later use.
  4. With JavaScript, apply the CSS transformations of scale and transform-origin to the body element of the page. Also, add transition: transform-origin .14s ease-in-out for extra smoothness.
  5. Grab the top and left corners of a given region when clicking on or double-tapping them.
  6. Use these values as the coordinates for the body element’s transform-origin property. You can now use the entire body as an auto-zooming map.
  7. Using Hammer57, update the coordinates of the next or previous region when swiping either left or right, to navigate back and forth between regions when zoomed in.

That’s basically how the prototype works. In this way, we can think of the body element as one big movable, zoomable map (or newspaper) that we are holding firmly in both hands. We are not collapsing the layout into blocks, as we do with classical responsive design; rather, we still see a large chunk of the entire website at once, with indicators (such as the larger headlines) that you can then zoom into.

The extra dependency on Hammer is not necessary, but it does make this kind of retrofitted zooming interface much easier to implement. If you’re not keen on adding dependencies, you can omit this and write your own handlers for touching, tapping and swiping.

You can check the prototype’s JavaScript source58. It would be amazing to see how you build on what we’ve written or take a different approach.

Starting From Scratch (Not Retrofitting) Link

How might one go about creating a hybrid zooming interface similar to Work & Co’s website, which we saw earlier? Here, we’ll walk through the steps of one way to build it (a rough prototype is available59, as well as a video60). I’ll spare you a long technical description and instead focus on sharing the gist of how it works. Feel free, though, to go through the source code61 and expand on it.

Note that we are using Jekyll and GitHub Pages as our foundation.

  • After creating the basic entry point for the website (i.e. index.html), create a nav element to use as the focal point for how users will explore and navigate the website.
  • Create the top-level pages (e.g. “About Us”, “Product,” etc.) somewhere where you can easily access them via AJAX or, in our case, through jQuery’s load method.
  • Wrap the contents of the pages in an element with the ID of content. You can name it whatever you want; it’s only needed to load particular fragments of the page in our zooming navigation.
  • Add links to the top-level pages to the nav element as something other than anchor tags, and add the data attribute data-href to them as well.
  • Add the permalink to each link’s data-href, so that we have something to hook into with JavaScript later. Using a CMS or anything that auto-generates a list of top-level pages and their permalinks will save you a lot of time.
  • Style the links as tap-friendly icons, including both the page title and a preview of whatever page each icon represents. Refer to the CSS62 and the prototype if needed.
  • Using JavaScript, load the contents of the top-level pages into each icon’s preview area. jQuery’s load method makes this very easy because you can use the data-href with the permalink defined earlier as the method’s destination. Refer to the JavaScript63 for details on how we did this.
  • With the contents of the top-level pages loaded into the icons, we can add more styles that determine how the content should look when in icon form and how it should look when the user zooms into the page. In our case, we’ve changed the flexbox flex-basis value and the font size of the page’s content. We’ve given the page’s content in the preview a very small font size and given the icon itself a flex-basis value of 50% when zoomed out. When the user zooms in, we scale up the font size and make the icon fill out the entire viewport, as you can see in the prototype64.
  • Finally, in the JavaScript, apply event handlers that toggle between the zoomed-in class and the zoomed-out class for when the user taps in and out of an icon. These classes will be responsible for scaling the font size up and down and for scaling the flex-basis value of the icon from 50% to 100%.
  • With these elements implemented, you can now tap an icon to see it scale up to full size, similar to Work & Co’s website and our prototype.

These steps provide a basic structure for the prototype explored throughout this article. As you might have noticed, we added some final touches in the form of CSS transitions to make the scaling feel smoother.

Also, while this is a mix of CSS and JavaScript, you could definitely implement this purely in JavaScript if you wanted to.

Even though this hybrid zooming interface is an interesting way to display a website’s pages, we need to keep certain things in mind if we want to maintain performance. Because we are loading actual pages in the previews, we should be careful about lazy-loading images, scripts or anything else that could be a burden on the initial loading of the website. So, be extra vigilant about lazy-loading images and so on if you end up building your next website with a zooming interface.

Conclusion Link

This article is the result of a lot of research. In our investigation, we didn’t find any solid reasons why a zooming GUI is not worth implementing. [965] Quite the opposite, in fact: Raskin’s idea holds a lot of promise.

Perhaps the reason why zooming interfaces are rare is that traditional HTML linking quickly became the dominant navigation paradigm, and zooming navigation presented problems of implementation.

We have good reasons now in a multi-device world to give zooming navigation another chance and to experiment with ideas and implementations.

Footnotes Link

  1. Google Maps66 and Sketch67 serve different purposes. While Google Maps may be defined as information software, which serves the human urge to learn and which helps people find information, Sketch may be defined as manipulation software, which serves the human urge to create. Bret Victor goes into this in depth in “Magic Ink68.” The fact that zooming navigation supports both kinds of software is another factor in its favor.
  2. Closure is the phenomenon of “mentally completing that which is incomplete based on past experience”. Scott McCloud thoroughly explains this ability of our mind in chapter 3 of Understanding Comics69.
  3. See chapter 2 of Don’t Make Me Think70 by Steve Krug for an interesting and illuminating essay on how we use the web. Jakob Nielsen comes to the same conclusion in “How Users Read on the Web71.” Also interesting by Jakob Nielsen are “Website Reading: It (Sometimes) Does Happen72” and “F-Shaped Pattern for Reading Web Content73.”
  4. The “learning time” of the new interface was measured. Other solutions “proved slower… and require excessive training.” Other metrics that Raskin considers important in assessing the value of an interface are speed of operation, error rate and ease of implementation.
  5. In the mechanics of Joni Korpi’s zooming navigation, the user would click the target element to zoom in and then press the “Escape” button or click a button in the bottom-left of the screen to zoom out. How the zooming in and out interaction works is critical to how “friendly” the interface is perceived to be. Each example we’ve examined has its own method, and Raskin has his own. We haven’t gone into detail with each method to avoid making this article run too long. That being said, while poor implementation could very well constitute the main thrust of the argument against zooming navigation, Google Maps and Sketch show us that doing it well is absolutely possible.
  6. Harlem.org74 is another example of an hybrid interface with specific use of the zooming mechanism. Clicking on any area of the group photo zooms us into a subset of the group, whereupon we can click again to zoom in on a single person to read their biography. This example was praised by Steve Krug as an effective instance of unconventional navigation. As everyone would agree, conventions are important in designing interfaces because they help users grasp things quickly; but if we always followed convention, we would never improve anything.
  7. Perhaps screen readers could be accommodated if we used some of the new voice-command plugins that activate the microphone. A blind user in a zooming interface would hear a website’s pages listed by the screen reader. On this page, you could say, “One for about, two for contact,” etc. If the user said “One,” the interface would zoom into the “About” page by triggering a click on that element.
  8. The NNGroup website has recently introduced a responsive layout, but that doesn’t change our reasoning. For the sake of argument, let’s imagine NNGroup didn’t introduce any layout change at any breakpoint.
  9. Raskin is also the name75 of a desktop application that adheres to the ideas of its namesake. From an informal survey of apps, we’ve invariably found that when some form of zooming is present in an app, navigation is great. For example, Workflowy76 zooms into a navigation sublist.

(vf, ml, al, il)

Footnotes Link

  1. 1 https://www.smashingmagazine.com/2016/04/inspiring-ui-demos-logins-menus-toggles-and-more/
  2. 2 https://www.smashingmagazine.com/2014/02/off-the-beaten-canvas-exploring-the-potential-of-the-off-canvas-pattern/
  3. 3 https://www.smashingmagazine.com/2016/05/smart-responsive-design-patterns-or-when-off-canvas-isnt-good-enough/
  4. 4 https://www.smashingmagazine.com/2015/03/simple-real-and-bug-free-foundation-development/
  5. 5 https://www.smashingmagazine.com/2013/04/javascript-plugin-for-responsive-navigation/
  6. 6 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-01-large-opt.jpg
  7. 7 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-01-large-opt.jpg
  8. 8 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-02-large-opt.jpg
  9. 9 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-02-large-opt.jpg
  10. 10 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-03-large-opt.jpg
  11. 11 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-03-large-opt.jpg
  12. 12 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-04-large-opt.jpg
  13. 13 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-04-large-opt.jpg
  14. 14 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-05-large-opt.png
  15. 15 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-05-large-opt.png
  16. 16 #f-1
  17. 17 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-06-large-opt.jpg
  18. 18 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-06-large-opt.jpg
  19. 19 http://techcrunch.com/2015/12/18/nielsen-facebook-remains-the-top-app-of-2015-but-messenger-was-the-fastest-growing/
  20. 20 https://en.wikipedia.org/wiki/The_Humane_Interface
  21. 21 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-07-large-opt.jpg
  22. 22 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-07-large-opt.jpg
  23. 23 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-08-large-opt.jpg
  24. 24 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-08-large-opt.jpg
  25. 25 #f-2
  26. 26 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-09-large-opt.jpg
  27. 27 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-09-large-opt.jpg
  28. 28 #f-3
  29. 29 https://www.smashingmagazine.com/2016/02/efficient-responsive-design-process/
  30. 30 #f-4
  31. 31 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-10-large-opt.jpg
  32. 32 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-10-large-opt.jpg
  33. 33 http://work.co/grid/
  34. 34 http://jonikorpi.com/
  35. 35 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-11-large-opt.jpg
  36. 36 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-11-large-opt.jpg
  37. 37 #f-5
  38. 38 http://desandro.com/
  39. 39 http://desandro.github.io/zui-site-riot/
  40. 40 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-12-large-opt.png
  41. 41 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-12-large-opt.png
  42. 42 https://en.wikipedia.org/wiki/Mode_(computer_interface)
  43. 43 #f-6
  44. 44 https://www.uie.com/articles/full_site_must_die/
  45. 45 http://alistapart.com/article/responsive-web-design
  46. 46 https://www.nngroup.com/articles/overuse-of-overlays/
  47. 47 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-13-large-opt.jpg
  48. 48 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-13-large-opt.jpg
  49. 49 #f-7
  50. 50 http://bencallahan.com/
  51. 51 https://speakerdeck.com/bencallahan/frontend-masters-responsive-web-design
  52. 52 #f-8
  53. 53 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-14-large-opt.jpg
  54. 54 https://www.smashingmagazine.com/wp-content/uploads/2016/06/ZUI-14-large-opt.jpg
  55. 55 http://andersschmidthansen.github.io/retrofit-zui-prototype/#0
  56. 56 https://drive.google.com/file/d/0B5ZGerMVkcq1X09qSW5XV1ZMUVE/view?pref=2&pli=1
  57. 57 http://hammerjs.github.io/
  58. 58 https://github.com/AndersSchmidtHansen/retrofit-zui-prototype/blob/master/js/main.js
  59. 59 http://andersschmidthansen.github.io/zui-prototypes/
  60. 60 https://drive.google.com/file/d/0B5ZGerMVkcq1ZUpuVUFkUi1rdjg/view?usp=sharing
  61. 61 https://github.com/AndersSchmidtHansen/zui-prototypes/tree/gh-pages
  62. 62 https://github.com/AndersSchmidtHansen/zui-prototypes/blob/gh-pages/css/main.css
  63. 63 https://github.com/AndersSchmidtHansen/zui-prototypes/blob/gh-pages/js/app.js
  64. 64 http://andersschmidthansen.github.io/zui-prototypes/
  65. 65 #f-9
  66. 66 https://www.google.it/maps
  67. 67 https://www.sketchapp.com/
  68. 68 http://worrydream.com/#!/MagicInk
  69. 69 http://scottmccloud.com/2-print/1-uc/
  70. 70 https://www.sensible.com/dmmt.html
  71. 71 https://www.nngroup.com/articles/how-users-read-on-the-web/
  72. 72 https://www.nngroup.com/articles/website-reading/
  73. 73 https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/
  74. 74 http://harlem.org/index.html
  75. 75 http://www.raskinformac.com/
  76. 76 https://workflowy.com

↑ Back to top Tweet itShare on Facebook

Luca Leone is a freelance self-taught interaction designer with a background in macroeconomics from his formal studies at Milano Bocconi University. He works with small and big companies on websites and apps projects. Follow Luca on Twitter.

Anders Schmidt Hansen is a user experience designer, developer and entrepreneur with a background in Information Science at Aarhus University, Denmark. He works in the intersection between entrepreneurship, web development and design. Follow Anders on Twitter.

  1. 1

    Excellent piece, but why no mention of the Android OS’ automatic zooming? My Nexus tablet zooms to every tap automatically, which is a beautiful thing for my aging eyes ;-) It does a fantastic job of this and makes even legacy/non-responsive/mobile-unfriendly sites easy to use. It’s a dead simple example that I can’t believe more products don’t follow.

    0
    • 2

      John Natoli

      June 3, 2016 2:33 am

      Sorry to go off topic but what the hell are the chances that I would find this article, read the entire thing, scroll to the comments and find yours at the top, Mr. Natoli?

      2
  2. 3

    Angus McIntyre

    June 2, 2016 2:08 pm

    Years ago, Apple had an experimental plug-in called HotSauce which read metadata files in a format called Meta Content Format (MCF) and generated a zoomable 3D fly-through of a website, called an XSpace.

    It was quite a neat trick, although lack of public interest and the need to install a special plug-in meant that it never really took off. Nowadays you could probably implement something similar using Javascript and Canvas.

    2
  3. 4

    I’m all for exploring new UI paradigms, but I’ve got some serious caveats about zooming in general.

    * It’s not very precise. On nearly every zooming UI I regularly use, from Google Maps to various Adobe apps, there’s always some miscalibration, overshoot, and re-zooming required. It’s much more efficient to just use the largest monitor I can afford.
    * Nearly every Prezi deck I’ve seen distracts from the content with its gratuitious flippy-zoomy motion.
    * Given that men in the tech field are over-represented, one might not be aware there’s a significant difference in how men and women react to motion, zooming, and VR; women generally get motion sickness much more than men do. (http://qz.com/192874/is-the-oculus-rift-designed-to-be-sexist/) Implementing zooming UIs might be great for dudes who play a lot of FPS games, but for women and people with vestibular disorders, it might make things totally unusable.

    7
  4. 5

    Looks like a little problem to Google Analytics engineers…
    how to measure and tracking without clicking…

    1
  5. 6

    I see a problem with using zooming navigation for larger sites with many navigation items and levels. Google Maps and Sketch have a visual layout as a basis that is know to the user – in Google Maps the geography of our world and in Sketch a layout the user defines himself when creating a document. Most information structures however do not have a logical visual layout that is intuitively understandable to all users.
    However for smaller sites or shops, zooming navigation may be worth a consideration.

    2
  6. 7

    I think this is great stuff. Zoomable UIs are definitely more intuitive and easier to follow than simply jumping around pages. Prezi was mentioned in another comment but I disagree, I think it works great and is a great analogy of the issue that traditional (i.e. Powerpoint) interfaces have. Prezi gives a clear understanding of hierarchy and positioning within the content that allows the reader/viewer to follow much more clearly.

    2
  7. 8

    I think ZUI will find a home on more immersive interfaces like VR and AR. Early looks at Unity’s in house game design VR interface show an immersive ZUI used for building and navigating 3D worlds for use in gaming. I suspect as VR gains traction we’ll see web content adapt. I think it is hard to authenticly create a ZUI on a 2D plain inside a rectangle. You end up with zoomy novelty like Prezi. Zooming will become natural to the UI when it has authentic depth and a z axis. This will honor our stereoscopic vision and feel more natural.

    1
  8. 9

    Never thought about zooming in 3D, very interesting point Brick, thanks for bringing this up, very interesting.

    1
  9. 10

    Different navigation patterns work for different business applications or websites. UI/UX design to navigate from one page to another should be different. The zooming effect works well in mapping but not on a business website. Similarly, an abstract view will work for designing application but not for any other tool.

    -1

↑ Back to top