UI Missteps: Form over Function

Don’t get me wrong. The people at MacUpdate usually do a great job of managing and taking user feedback. But even with their careful curation of Mac & iOS apps that receive updates (sometimes numbering close to 100 OS X apps alone in one day), things slip through the cracks. I wasted about 5 minutes trying to figure out why an updated app was not available via one-click update using the built in software updater nor MacUpdate’s Desktop app. After going to MacUpdate, it was only by reading the comment and then hovering above the download link that the answer was clear: the app was a beta, and using the built-in update tools both within the native app & the MacUpdate Desktop App wouldn’t work. Even though I have “show beta/pre-release” unchecked, it still showed up in the MacUpdate Desktop list.

I realized the problem when looking at the comment and the confusion about version numbers used and how Adobe doesn’t distinguish betas with “b” or “(beta).” Then I took a few minutes to write this. The focus is not what MacUpdate did — it is an edge case which reflects more poorly on Adobe. Instead it is a example of what UI designers everywhere are doing to the detriment of both advanced and novice users everywhere.

Making Simplicity Difficult (Form Over Function)

If you accept that the purpose of computers is to make tasks easier to accomplish than doing them without them, then what follows is logical. When the interface gets so polished the labels are rubbed off, advanced features are hidden or removed, and labels are replaced unlabeled/undocumented icons, it leads to problems using an application no matter what type of device the application runs on. Here is my brief comment on that.

I don’t mind clean, nice-looking interface (I strive to balance aesthetics with easy-to-access, powerful features), but don’t let streamlined designs actually slow productivity; whether that productivity is actually getting work done or doing administrative tasks such as updating your software.

This confusion is a clear case of form over function, which is the wrong direction (unless you’re selling soda or commodities…) for computing interfaces to head because it handicaps learning via obscuring helpful, orientating/navigating details and slows advanced users.

If the trend in UIs were to spill over in the real word, we would see street signs replaced with pictures of maps and street addresses removed from the front, and instead only inside each building. Menus boards would have descriptions and prices hidden, until a person opened a flap to read the price and description.

In houses rather than work aesthetics around function, some streamlined houses would only have one control panel that controlled all the lighting, heating, etc. but that panel would be fixed next to the circuit breaker box. If a house had individual light switches, they’d be placed at whim of a designer who never lived or had even been in a house. Some would be oriented at any angle the designer liked and on any surface — some nowhere near the door or on one or both sides of the door. Some switches would glow only when they were off, and not when they are on, and vice versa which is actually happening with electronic switches. All building layouts would depend on the whim of a designer that had no concept of architectural design patterns nor a care about the building’s function.

This current trend toward “flatness” that was a backlash against “skeuomorphic” design of last generation all dance around the real point of GUIs: to make things easier by giving feedback to users that allows them to assess both current application state and orient where they are in the system. The trend is stripping away both of these, making things harder to use, not easier. Sadly, people think simplifying the interface will help users whose learning is being retarded by confusing inconsistent and low-feedback designs. This over-simplification is in fact hurting more than helping. This is because simple is not necessarily a synonym for easy. (Easy things are simple, but simple things are not always easy oddly enough.) Product managers and designers think people want simple, when they really want easy. Making things easy should be the focus. The easier a more complex the task is, the more useful your software.

Making Complexity Easy (Form Follows Function)

Designers should look for the frustrating points and the complex points and make complex tasks as easy as possible — which means removing steps if it can be done without making the user’s knowledge have to ramp up greater than the complex steps.

This is my Menubar. This is easy:

menubar

It is very dense with information. By looking at it you can see with a glance that Bluetooth is on, I’m connected to the network with light traffic, my processor load, my sound volume, the day & date, my current battery level (full) & that I am plugged in, the time, the moon phase, the CPU temperature & CPU voltage draw. I could have the default OS X menubar, but then I wouldn’t be able to see this without opening applications, slowing me down. I often refer to network speeds and CPU load when something seems bogged down. I often check the date and time, and that calendat icon pulls down so I can see my schedule in Fantastical without opening the Calendar App. The functionality is available if I pull down my sound menu is Audio Switcher.

audio-switcher

All these save me time each use. The march of Menu Items and GUI Enhancements I use all take a complex array of data, navigation, and bother of doing complex things and make some of them a click or less away. While this might be ugly to some, it is not distracting and works well. This is my current balance point, but with each stripping down towards “simplicity,” this ease becomes more difficult. Thankfully the developers of iStat Menus, Fantastical, Bartender, Audio Switcher, Moom, TotalFinder, Default Folder X, Alfred and PopCar (among others) see the problem that streamlined interfaces bring. But rather than strip away information, they strive to arrange information in a way that is not overwhelming and give user configurable interfaces to really harness the power of a GUI. These companies (while not all perfect — some have fallen into this hole at least slightly) have UI designers, not artists making flat colorful mystery icons with unpredictable UIs that confuse people calling themselves UX designers.

(I think of myself more as a User/Communication Efficiency type of person, so while the “UX Designer” title sounds fancy, I’d rather be a “User Interface Communication Efficiency Designer” to put the emphasis not of the “experience” of using a product, but on the efficient use of communications media available. Plus, UICED sounds like a term that could be played with. But titles are kind of limiting in a way… so I’ll just be myself. When people ask me my title, I just sum it up to say “IT Consultant” since whenever I actually start to talk tech I notice most people’s eyes glaze over.)

I try to focus on what matters to get work done, so I can get work done with less effort and faster. Anything that gets hinders more than helps my efforts falls out of use. BTW, if you are not familiar with these products, many are mentioned and linked on my Recommended Apps page. You can also check out MacUpdate.com and see the trove of software — most at least decent — that they list. They are good guys, so if you see errors, write them and be nice please. They will get back to you if needed with a personally written reply, which is always worth a star in my book. “When I was a kid several days of Mac SW updates could fit on one page… now several pages might span one day.”

Thanks for reading.

Advertisements

Developing Web Sites on OS X Faster & Easier

I often get asked what I use to develop web pages and other types of documents on OS X. Sometimes it is from new users, who have switched from a Windows environment who genuinely want advice. Sometimes it is a loaded question from a developer with a Windows bias and outdated information who thinks that developing on OS X is more difficult and clunky compared to Windows (or Linux). In some cases it is (such as if you are trying to develop for a Windows .NET system) because OS X is a Unix derivative, Windows’ naming schemes (such as the path separator and old text encoding) makes it a pain. However, for apache development, most web libraries and applications simply need to be configured and installed for OS X’s flavor of unix to work. Many offer native precompiled apps. At one point setting up a basic Web Server in OS X was a simple matter of dropping files in /{username}/Sites/ and going to System Preferences>Sharing>{selecting} Web Server. However, because Apple now confuses simplicity with ease [1. a subject I comment on from time to time.]— it has followed a trend of removing a lot of the convenience features for starting standard unix services such, from the default install of OS X. Now, things are less straight forward for developers who just want to toss up a quick php server to develop locally, and some people now need help setting this stuff up, and would rather not have to learn the terminal commands. Others, like me, know the terminal all too well, but are tired of having to edit file after file (taking care not to make a single mistake) and restart services when throwing a few switches and typing a few lines in the terminal is so much faster and practically immune to error.
No matter what your angle is, I get asked often enough how to get started or what I use, that I have decided to write it down so I can point people to this article. While not exhaustive (I do not have unlimited funds to try every IDE, or app that increase productivity), this is what I currently use. For the most part I like it, but try to avoid being too biased because I realize everyone has different needs and different preferences on how things should work. So, as usual: YMMV.

Continue reading

Q: Why Join App.net? A: Privacy & No Advertising

App.net might look like just another social service to some. And, in fact, it currently looks very much like Twitter was when it started: It is just a lot of tech-savvy people talking freely and enthusiastically about app.net and whatever strikes their fancy: No celebrities promoting themselves, no ad-spam, no fake users, no incredibly stupid posts—although there are some stupid posts, there’s no one stupid enough to post public calls to kill government officials as one woman who has disappeared did. App.net is just a lot of signal with very low noise.

I get at least a few invites each month to join a new SoNet. The invites usually get a tossed into the trash almost immediately. Few get me to look at the site. But that’s usually it. Even if I do sign up the to site, I often let it languish and simply forget about it until they start spamming me to use their site, “log in with…” or want me to link my other SoNets to it.

Paying not to Share but Selectively Share

App.net is 180° away from ll of these sites though, because their interests align with my interests:

Continue reading

TouchUI: The Misunderstood Paradigm, Part 2 is Out

It seems like only months ago I wrote this entire article in one sitting after pulling out comments I made to Mark via email on Josh’s views. Then had to mercilessly cut out about a third of it and rewrite parts over the next few days. But that’s because I’m old, and going off on tangents is the law. That or I have a lot to say about UI. So, what do I touch on (no pun intended) in part 2? You’ll have to read it to find out.

http://news.dice.com/2012/08/21/touchui-misunderstood-paradigm-2/

TouchUI: The Misunderstood Paradigm Excerpts

Part 1 of my 2 part article on TouchUI is now up on DiceNews. In it I talk about the current state of TouchUI in the setting of responding to Josh Clark’s views on it. I want to make it perfectly clear, I think he is on the right track. However, he seems to miss some of what we have learned about user interfaces the past 25+ years.

In order to fit in the format, I pulled a section of the article where I brainstormed about how I believe a TouchUI should work as a foundation for adding custom gestures and interfaces. There are probably problems with some of these ideas, but it is just a cursory glance at what a baseline UI should have. I am throwing it in here for your consideration. As always: intelligent feedback is welcome.

Some are obviously inspired (“ripped off”) from WebOS, and some are from Android and iOS. However, for the most part a cohesive convention of how things should be done that is translatable to all manner of touch screens has not emerged. This is my “first” public swing, but I think about this stuff all the time, especially whenever I am using a frustrating interface. Continue reading

Quick Shot: Too Long for a Tweet, Too Short for a Page

Okay,

Quickly: This month has been a “lurning [sic] experience.” I am juggling multiple projects which are all related only by the fact that they’re simply making me a better designer. New tricks are being learned, etc. Sites are going up and being moved, and I’ll be updating everything and essentially leveraging what I learn in one place and using it in another.

I finally figured out I needed to buy more RAM for my laptop: sometimes there is less than 16MB of free RAM and over 700K page-outs in a few days of heavy use. The thing would slow to glacial pace during heavy loads. It’s really been holding me back. Who knew 4GB wasn’t enough!?!? So, I broke down and ordered a few more gigs. Luckily, installing is a piece of cake on my MBP. I was in and out of a friend’s machine in less than 15 minutes without cutting any safety corners. I also need to get another HD and replace the optical drive. OR I can just breakdown and backup over WiFi and offload some files. But I like the idea of having everything with me.

Another, non-web, but information related project is advancing slowly, but it is way too soon to even talk about. I am still researching to decide the best approach. Some of my closest friends know about it, and I think about it all the time. It is currently possible: all the building blocks are there, but no one has put them together yet. I should probably stop spouting off about it to people who work for huge computer companies though. But for all I know someone has already patented it? I dunno, I heard if you research a patent it is worse if you get sued. :\

Anyway, my plan is to release it under a non-commercial open licensing scheme, so that pizza fueled one man ops can use it freely, and large corps that can pay may license it. But as I said, someone might have already patented the pieces, but I think this would probably fall under derivative works. I’m not sure because I am not a patent lawyer. It sucks that I have to keep the cards close to my vest because copyright: originally designed to encourage innovation, is now a club that large corporations use on each other daily. Recently I read about a patent lawsuit about emoticons in a pull down menu on Ars, It seems silly to anyone, but that’s how whacked patent law is. The funny thing is, within my circle of friends I probably have all the people I would need to start developing this thing in earnest, but first I’ll go in sideways with build-up projects.

A big thanks to those people with everything from bachelors to PhD degrees in CS and related fields that I have the greatest conversations with. I learn something new every time I get a chance to pick one of these people’s brains.

Apologies about any incorrect punctuation marks or typos. I’m typing this on the fly before heading off somewhere. Cheers!