3 ms·
It feels good to see UX design becoming an important part of writing software, and it feels even better to see people favoring clean, minimalistic UIs built wit
by GeneralMaximus 15y ago
It feels good to see UX design becoming an important part of writing software, and it feels even better to see people favoring clean, minimalistic UIs built with icons and guestures in mind rather than the button-and-text-heavy UIs that were the norm until just a few years ago. But sometimes I'm afraid this new trend might be taken too far.
As we begin to rely more on gestures and (unlabelled) icons instead of menus and (labelled) icons/buttons, we create a new language of pictures and hand movements. This is not a bad thing. Pictures are easier to process than text for a majority of the population. UIs become simpler, uncluttered and generally feel more "loose" and "free flowing", and hence more fun, with gestures. All this is great, but I see a couple of issues with these "primal" methods of working with user interfaces.
The first issue is discoverability. Unless they are explicitly pointed out to them, it's difficult for someone to find out that guestures even exist. [Aside: non-discoverability is an attribute guestures share with keyboard shortcuts, except the keyboard shortcut for any action can be discovered just by looking to the right of that action's label in the app's menu system. This is possible because we've given names to all our keys and therefore we can just write shortcuts out as plain text (Ctrl+A, Ctrl+Z, etc.) Perhaps ... perhaps we could start representing guestures by a standard set of symbols so we can refer to them as easily as we refer to shortcut keys. For example, ⇠ could represent "swipe left", ⇢ could be "swipe right", ╳ could be "pinch to zoom", etc. Even then, the issue of discoverability remains with touch UIs, where there are no menus where we can stick these symbols, no status bars, and often no manuals.]
Second, icons are often vague. The cognitive overload of figuring out what a particular icon means is sometimes just too much. I've personally been frustrated by having to hover my mouse over an icon, waiting for a tooltip to appear, then finding out that the icon doesn't do what I need and having to again hover my mouse over a second icon, waiting for the tooltip gods to enlighten me. Tooltips are not possible in touch UIs, so on tablets you just have to pick an icon and hope for the best. It doesn't help that many apps don't have a visible "Help" key. The solution here, I believe, is to very carefully choose which icons in your UI you want to label and which are obvious enough to remain unlabelled.
Third, menus lend interfaces a sense of hierarchy. Hierarchy is a great navigational aid for situations where you have to choose between a large number of items. People instinctively understand hierarchy. We've spent centuries classifying information into hierarchical structures, and now suddenly UI designers are ready to disregard the benefits they bring. Case in point: replacing the hierarchical menus of GNOME 2 with an icon grid in GNOME 3 and Unity. Apple made icon grids popular with their iDevices and OS X Lion, but I think Apple is the worst possible company to emulate when it comes to building efficient, useful interfaces. If you're looking for shiny and cute, sure. Usable, even. But efficiency and usefulness are concepts Apple does not understand. The icon grid is possibly the worst possible way of navigating through applications if you have more than 5 of them. With 30-40 apps, the icon grid quickly becomes useless and you have to rely on the search function to get to what you need.
Fourth, with icons and guestures, knowing the "language of software" becomes important. You can't just hunt around in the menus and figure out how the app works on your own. No siree, you need to RTFM or watch a tutorial video. That's fine when you're learning Photoshop, but RTFMing for simple mobile apps? Not happening.
Fifth, icons make communication difficult. How do you give someone instructions on how to perform a task over email when the app she is using uses unlabeled icons and guestures for everything? How do you describe the undo icon over email? While I was writing this reply, my mother called me asking how she could pause and un-pause a TV show on a Tata Sky HD+. I told her to "press the button with the two parallel lines for pause, press the tiny triangle button to play". Not that big of an issue with pause/play/rewind/forward buttons, since they're standardized and look exactly the same on all multimedia hardware and software. But what about, say, the buttons in GMail? How do you describe the "Archive" button to your iPad-using mom? How do you describe the "pinch" guesture used to close an app on the iPad?
So what is the point I'm trying to make with this immense wall of text? My point in a nutshell is that while a lot of UI paradigms that are making their way from the world of tablets to the world of PCs make sense, their overuse often renders UIs confusing and vague. I'll admit this is not that much of an issue right now, but it might become one very soon. I'm afraid there might come a time when all UIs cater to what I'm going to call "casual" users and people who actually use computers for work are left out in the dark.
- commieneko 15y agoNormal people hate hierarchies. I've spent a lot of time trying to teach non-programmers to us them in their work flow. There is no question that they are useful, but people resist them fiercely. Many developers have a hard time dealing with this and are as resistent to acknowledging this limitation, or feature, of human behavior as most people are to using said concepts. In a lot of ways this is understandable. You don't see many directly manipulate hierarchies in nature. People can deal with piles, and one or two dimensional arrays, and even arrays of piles. And they can deal with sorting and stashing. More importantly, they can deal with ask and tell. I've played with various stack based interfaces and while they are interesting, I haven't found any that I really like, much less that seem generally extensible. I dont have any great ideas here, sometimes I think the answer is to let the user dig holes in the desktop and bury what they aren't working on in little treasure caches; this essentially describes most users' desktops anyway. how you would go about generalizing this to, say, a CAD system interface is another question...