The Same User Interface Mistakes Over and Over(prog21.dadgum.com)
prog21.dadgum.com
The Same User Interface Mistakes Over and Over
http://prog21.dadgum.com/214.html
88 comments
Agree. I avoid updating apps that are working satisfactorily because many later add ads or other annoying functions.
Or remove functions, or change the UI needlessly and for the worse. I honestly don't know how people can update their apps without having a backup to go back to. I probably would not do it if I didn't have one of my backups around. The different app stores should offer the user a way of going back to a previous version (if you already had it installed) but it seems that none of them do so...
Apple's "app thinning" feature implementation in iOS 9 makes it all the more difficult to "save a version of an app" because iTunes no longer syncs apps into the computer, like it used to before. Any app downloaded on to the device directly from the app store is a device specific thinned version. If you replace the device with a new one, you would have to just get all the latest versions of the apps from the app store. The only inconvenient solution, in my knowledge, is to always purchase and download apps and even update apps from iTunes on a computer. This would make iTunes download a "universal" (for lack of a better term) app file that would run on all compatible devices. Then sync the apps from iTunes to the devices. You lose the advantage of app thinning and use more storage (like in iOS 8 and previous versions), but you would have access to the specific version that you have used and want to keep using.
I emphasized the word "implementation" above because it was not necessary for Apple to disable iTunes from syncing apps on to a computer with the thinned apps. Technically, there are many ways to store device specific copies of an app with the same name on the computer, which for some reason Apple has not even considered. [Apple never allowed downgrading of apps without resorting to iTunes, but that's a different and larger topic]
Overall, the push to use the latest version of any app is really frustrating and will result in more backlash as people realize how much freedom they're losing.
I emphasized the word "implementation" above because it was not necessary for Apple to disable iTunes from syncing apps on to a computer with the thinned apps. Technically, there are many ways to store device specific copies of an app with the same name on the computer, which for some reason Apple has not even considered. [Apple never allowed downgrading of apps without resorting to iTunes, but that's a different and larger topic]
Overall, the push to use the latest version of any app is really frustrating and will result in more backlash as people realize how much freedom they're losing.
As an app developer, I understand the frustration but you've got to see the other side too. There's a huge cost to maintaining legacy server side API end points. I think the sibling commenter makes a great point about the difference between standalone apps and apps that are a client to a web service. It's also very frustrating when I see a crash keep happening in my error logs that I know is fixed in a later update :(
Mind you, there's a large difference between standalone apps (e.g. most casual games), and client-server apps. Standalone apps—sure, don't update, who cares.
But I don't begrudge the developer of a client-server app, that wants to change their server's API and then push an update to the client that speaks to the new API. Or, more to the point, I don't begrudge them if six months later they shut the old API down and the app stops working until I update. It's a client-server app in an ecosystem where updates are supposed to be automatic; of course it needs to be up-to-date to work. Would you expect to play e.g. an MMO without installing the updates before connecting to the server?
But I don't begrudge the developer of a client-server app, that wants to change their server's API and then push an update to the client that speaks to the new API. Or, more to the point, I don't begrudge them if six months later they shut the old API down and the app stops working until I update. It's a client-server app in an ecosystem where updates are supposed to be automatic; of course it needs to be up-to-date to work. Would you expect to play e.g. an MMO without installing the updates before connecting to the server?
I have seen applications that check the version on launch, inform the user about an update being available and in some cases also prevent the app from running further if it's not updated. Technically this is just a matter of writing the application this way. Even though users may be inconvenienced and annoyed, if the application and its service have not been terrible and if you follow a proper "deprecate and then eliminate" process, most users wouldn't mind updating on a prompt that comes at launch time. More so if the "what's new", along with a "why update" is described on launch. Nothing stops a developer of a client-server application from developing this way.
[deleted]
Also automatic application updating (default on since iOS8) mostly solves the problem for people who aren't choosy about updates.
If you decide to study how to build bridges, you will start out with calculus, build a background in science of materials and then a guided tour of approaches to structure-building. In addition, you have to learn typical environmental factors. And, of course, there are workflow patterns and human factors involved in actually constructing a typical bridge. Oh, and sure, there will be a bit of CAD.
Let's apply this metaphor to programmers working on UIs: a huge chunk of practitioners right now get by via simply having learned a bit of CAD (i.e. HTML/CSS/JS). And also, yeah, they have walked over a bridge once/seen a panoramic postcard, so there's that. Very ad-hoc, very disorganized, full of gaps.
Of course the impact of mistakes is magnitudes different between designing bridges and building UIs. Except for when that UI drives medical automation. Or finance (one of my faves is an anecdote about how a bad input form field cost a fund management company literally in the 8 digits of money).
Our industry is of course very young, and so I think this education gap is simply a temporary issue. I am looking forward to (and am personally investing into) a day when there will be a more systematic and comprehensive education on how what a good UI looks, behaves and feels like, not just how to code buttons and boxes on a screen.
Let's apply this metaphor to programmers working on UIs: a huge chunk of practitioners right now get by via simply having learned a bit of CAD (i.e. HTML/CSS/JS). And also, yeah, they have walked over a bridge once/seen a panoramic postcard, so there's that. Very ad-hoc, very disorganized, full of gaps.
Of course the impact of mistakes is magnitudes different between designing bridges and building UIs. Except for when that UI drives medical automation. Or finance (one of my faves is an anecdote about how a bad input form field cost a fund management company literally in the 8 digits of money).
Our industry is of course very young, and so I think this education gap is simply a temporary issue. I am looking forward to (and am personally investing into) a day when there will be a more systematic and comprehensive education on how what a good UI looks, behaves and feels like, not just how to code buttons and boxes on a screen.
Meh. If you read The Design of Everyday Things and then look around, you see so many faults with the UI of physical things, even some which have been around for more than a century.
A good example is packaging: "The Consumer Product Safety Commission estimated that attempts to open packaging caused about 6,500 emergency room visits in the U.S. in 2004."
A good example is packaging: "The Consumer Product Safety Commission estimated that attempts to open packaging caused about 6,500 emergency room visits in the U.S. in 2004."
I think many of these problems aren't caused by someone unable to construct a good UI, but that the manufacturer's other goals happen to be opposed to good UI. UI is just not high on the priority list and is inadvertently trampled on.
E.g. clamshell/tamper-proof packaging is awful (I like calling it "customer-proof"), but the goal to reduce theft is a much higher priority than making it easier to open.
E.g. clamshell/tamper-proof packaging is awful (I like calling it "customer-proof"), but the goal to reduce theft is a much higher priority than making it easier to open.
I highly recommend The Design of Everyday Things to everyone I know who is designing any kind of user interface, whether machinery, houses, or software.
I believe that until there is some effective, easy, and universally-accepted metric of UI quality, there will be little to differentiate good designers from poor. ("Our UI meets UIQC Class 1 Standards", or in a specification, "All user screens must score level 96 or better on the UIQC test", or some such thing.)
I believe that until there is some effective, easy, and universally-accepted metric of UI quality, there will be little to differentiate good designers from poor. ("Our UI meets UIQC Class 1 Standards", or in a specification, "All user screens must score level 96 or better on the UIQC test", or some such thing.)
There is the multi-part ISO-9241 that covers the ergonomics of human-computer interaction. It even provides a definition of usability.
I don't believe user interfaces could be evaluated in such a quantitative and useful way, as you describe. You could slap some number in there, but that doesn't make it useful.
Bear in mind that the UI itself is just a part of the equation, alongside the user and the usage context. Two identical UIs (evaluated at about the same score with the hypothetical UIQC) can perform radically different in the hands of the end-user, because the users and their contexts are different.
Bear in mind that the UI itself is just a part of the equation, alongside the user and the usage context. Two identical UIs (evaluated at about the same score with the hypothetical UIQC) can perform radically different in the hands of the end-user, because the users and their contexts are different.
>with the UI of physical things
That's not the building bridges level engineering that the parent talked about.
In fact, any designer/CAD hack in some factory can get his hands in building packages or other physical items, so the situation is mostly the same as the one the parent criticizes. In most countries you don't need to have an engineering degree to design a package container, kitchenware or a toy car -- at best an "industrial designer" degree will do.
That's not the building bridges level engineering that the parent talked about.
In fact, any designer/CAD hack in some factory can get his hands in building packages or other physical items, so the situation is mostly the same as the one the parent criticizes. In most countries you don't need to have an engineering degree to design a package container, kitchenware or a toy car -- at best an "industrial designer" degree will do.
I don't think that's a good example. Packaging is deliberately designed to be hard to open as a theft deterrent mechanism.
Some packaging may be designed in this manner, but that's bad (or simply lazy) design. Packaging can, and should, serve the interests of the manufacturer, retailer, and consumer equally well.
Some packaging is theft-resistant, but can be 'unlocked' by the retailer at POS. I'm thinking, in particular, of razor blades in the UK. Is that the best compromise?
I assume you're talking about spider wraps [1] - a wire that goes around the box and connects back to a little lock.
As a consumer, I don't like these because the lock portion often obscures an important piece of information on the box. They also don't work for packaging that's designed to be manipulated on the shelf, e.g. boxes with a magnetically attached book-style cover that let you examine the product or read more information by opening it [1].
They're not ideal for retailers, either. They detract from the the aesthetic appeal of the packaging - reducing sales - and increase labor costs by adding extra steps (and, thus, time) for employees stocking shelves and working at the POS.
EAS systems (the little RF tags that are deactivated by placing them on a pad at the POS) are probably the best things going right now for passive deterrence, but they have their own set of problems (e.g. false positives).
1. https://www.americantheftprevention.com/uploads/2Alarm_Mini_... 2. http://www.pcgameware.co.uk/images/CM-Storm-Pitch-Pro-Gaming...
As a consumer, I don't like these because the lock portion often obscures an important piece of information on the box. They also don't work for packaging that's designed to be manipulated on the shelf, e.g. boxes with a magnetically attached book-style cover that let you examine the product or read more information by opening it [1].
They're not ideal for retailers, either. They detract from the the aesthetic appeal of the packaging - reducing sales - and increase labor costs by adding extra steps (and, thus, time) for employees stocking shelves and working at the POS.
EAS systems (the little RF tags that are deactivated by placing them on a pad at the POS) are probably the best things going right now for passive deterrence, but they have their own set of problems (e.g. false positives).
1. https://www.americantheftprevention.com/uploads/2Alarm_Mini_... 2. http://www.pcgameware.co.uk/images/CM-Storm-Pitch-Pro-Gaming...
Lets say conservatively that 70% of Americans open at least one package a year, equalling 223,230,000 packages opened. 6,500 injuries is 0.0029%. Not bad I think.
0.0029% for injuries that require an emergency room visit, not injuries at all. Let's go for a conservative, 100:1 ratio of minor cuts vs injuries that make you want to spend a bunch of money on doctors, and we see that it's pretty darned dangerous. Dangerous enough that at work, we have mandatory training on how to open different kinds of packages safely!
That said, the state of blisters has improved, precisely because people complained about how easy it is to get injured with the older, plastic on plastic blisters that require either heavy duty scissors or a box cutter, and leave behind very sharp edges.
That said, the state of blisters has improved, precisely because people complained about how easy it is to get injured with the older, plastic on plastic blisters that require either heavy duty scissors or a box cutter, and leave behind very sharp edges.
>0.0029% for injuries that require an emergency room visit, not injuries at all.
If you get an "emergency room visit" for trying to open a package, there's also some sort of idiocy involved.
I wonder if the level of E.R visits would for perfectly designed packages wouldn't be close or similar, because of idiocy.
If you get an "emergency room visit" for trying to open a package, there's also some sort of idiocy involved.
I wonder if the level of E.R visits would for perfectly designed packages wouldn't be close or similar, because of idiocy.
You've probably been downvoted (although, not be me) for using the term 'idiocy' which is a really unfair and derogatory accusation. I've cut myself on packaging before, definitely. I've probably done it in the past year. I am not 'an idiot'. ER visits could be for a number of indirect reasons; blood disorders that could prevent blood from clotting affect at least 6,500 people in the US. Just because the injury you're imagining wouldn't be serious to you, doesn't mean others are 'idiots'.
>* I've cut myself on packaging before, definitely. I've probably done it in the past year. I am not 'an idiot'.*
Well, I've cut myself too. That's not the problem.
It's the E.R level injury though that I say implies some incompetence.
And if they have "blood disorders that could prevent blood from clotting", they shouldn't mindlessly be using knives and other sharp objects to open packaging.
Well, I've cut myself too. That's not the problem.
It's the E.R level injury though that I say implies some incompetence.
And if they have "blood disorders that could prevent blood from clotting", they shouldn't mindlessly be using knives and other sharp objects to open packaging.
another example would be petrol/gas station pumps:
http://www.olivierlorrain.com/2009/06/20/bad-design-gas-pump...
Another example of bad UI of a sort: comment form spam, demonstrated by the last two comments on your link.
I work in product development for things that have mechanical and electronic bits, etc. There are disciplined processes for designing things, typically applied to life support systems such as bridges and jet planes. Or, hi-reliability components like hard drives.
But outside of life support products, I would guess that the majority of product development is only as disciplined as it needs to be, for what's being made. A lot of stuff is designed by seat-of-pants, by people sitting at CAD stations who mostly have engineering degrees but don't engage in engineering and have forgotten all of their math and theory.
The level of organization and discipline needed to do things like design airplanes is done by the segment of engineers who enjoy that discipline and gravitate towards those industries. People who prefer to do seat-of-pants design find their own niche as well. At my workplace, I can't count the number of times I've heard: "But we don't design airplanes here." Our stuff works when it gets to the customer, but if you scrutinize our designs the way we've all been trained to scrutinize UI's, you'd be horrified.
But outside of life support products, I would guess that the majority of product development is only as disciplined as it needs to be, for what's being made. A lot of stuff is designed by seat-of-pants, by people sitting at CAD stations who mostly have engineering degrees but don't engage in engineering and have forgotten all of their math and theory.
The level of organization and discipline needed to do things like design airplanes is done by the segment of engineers who enjoy that discipline and gravitate towards those industries. People who prefer to do seat-of-pants design find their own niche as well. At my workplace, I can't count the number of times I've heard: "But we don't design airplanes here." Our stuff works when it gets to the customer, but if you scrutinize our designs the way we've all been trained to scrutinize UI's, you'd be horrified.
While on the topic of airplanes, we shouldn't think they have perfect user interfaces. There have certainly been some design choices that should be criticized, and likely contributed to people dying.
https://en.wikipedia.org/wiki/Air_France_Flight_447#Human_fa...
https://en.wikipedia.org/wiki/Air_France_Flight_447#Human_fa...
A bridge supporting a weight load of X in wind/water conditions Y is a testable thing.
A UI that is "easy to use", "intuitive", "has the things you use most front & center", etc, are all soft subjective terms. Even when you run stats over a population to try to find generic mediums, those overall expectations will change over time as well.
A UI that is "easy to use", "intuitive", "has the things you use most front & center", etc, are all soft subjective terms. Even when you run stats over a population to try to find generic mediums, those overall expectations will change over time as well.
Where/how do I learn good design? I'm an iOS developer with just under a year of full-time experience. I have never had to design anything at work, and I'm painfully aware that my design skills are horrible.
Request to all designers - please stop building nested scroll and drag interactions. Common pet peeve for me recently is embedded map widgets in web pages. A user scrolling the page will find at some point that their mouse has come over a map which is now eating the scroll events and they are now scrolling the map instead. Only choice at that point is to move the mouse over and start scrolling over. Bonus annoyance - In many cases it is non trivial to reset the map to its default setting before the unwanted scroll interacted with it. Hovering over an item is a very weak commitment from the user that they want to interact with the element. Please do not use the hover to infer that the user means to interact with the element, at the very least put in some kind of timer and enable the interaction only on sustained hovers.
"A user scrolling the page will find at some point that their mouse has come over a map which is now eating the scroll events and they are now scrolling the map instead."
This annoyance has been widely extant for ten years or more - I think I first experienced it with google maps as I believe they were the first to zoom with scroll ...
Seems easy to fix - sub window elements in the browser cannot zoom until clicked on ?
It's amazing that behavior made it through one browser version iteration.
This annoyance has been widely extant for ten years or more - I think I first experienced it with google maps as I believe they were the first to zoom with scroll ...
Seems easy to fix - sub window elements in the browser cannot zoom until clicked on ?
It's amazing that behavior made it through one browser version iteration.
As long as you also track "going out of focus" , to disable the scroll capturing again.
Courseware MOOC platform nests things it's so amazingly bad. I forgot how bad it was.
Can we talk about search dialogs that are not actually dialog boxes ?
I first saw it at netflix - instead of a search box in the upper right, there is a picture of the word search and if you click on that picture of the word search it becomes a textbox[1] that you can type into.
As if that's not bad enough, the word "search" can turn into a textbox faster than it takes to fully load the control, which means you get the textbox but cannot type into it for another few moments.
How much of an unimaginable asshole do you have to be to pervert a basic web UI component like this ?
[1] No, of course not a real textbox - some 50 kilobyte control from some web-authoring toolkit that masquerades as a textbox.
I first saw it at netflix - instead of a search box in the upper right, there is a picture of the word search and if you click on that picture of the word search it becomes a textbox[1] that you can type into.
As if that's not bad enough, the word "search" can turn into a textbox faster than it takes to fully load the control, which means you get the textbox but cannot type into it for another few moments.
How much of an unimaginable asshole do you have to be to pervert a basic web UI component like this ?
[1] No, of course not a real textbox - some 50 kilobyte control from some web-authoring toolkit that masquerades as a textbox.
That's what Netflix got from using Reactjs. Facebook people search on mobile page version uses React too. It worked very well as a traditional AJAX search. Then they changed to to use React and now it takes a second or two to initialize and load the page (even it is in cache). And the search textbox doesn't feel like a native textbox, it's very laggy and shows inputs way too many milliseconds later. And on top of this the search result adds another delay. So searching for "Joe doe" means a laggy delay for every character as you try to type it in. Why? It tries to guess the person after every keyboard change event. Something that worked fine with the original AJAX version (Facebook optimized that version a lot an blogged about it / wrote a paper). Sadly with the React rewrite the forgot to read their own blog and probably React is an overkill for such a type of page and consumes to much CPU cycles on mobile devices. If you have to refresh 90% of the search results page anyway, why use React? Building and diffing a VirtualDOM isn't cheap (and ShadowDOM isn't supported), and it would be a lot faster to simply overwrite the DIV with innerHTML and traditional vanilla Javascript AJAX. Use the right tool, don't use a hammer for everything.
>That's what Netflix got from using Reactjs.
...for using Reactjs badly. IFTFW.
First, they could have had the item as a search box from the start, no need to make a label that when clicked turns into a search box.
>* If you have to refresh 90% of the search results page anyway, why use React? Building and diffing a VirtualDOM isn't cheap*
Actually it can be as cheap as directly changing the DOM with JS. And diffing can be just a single op e.g. when using an immutable data structure for their always changing part of the data.
It's just a change done crudely, not even non-optimized, because it doesn't need that much optimization anyway.
...for using Reactjs badly. IFTFW.
First, they could have had the item as a search box from the start, no need to make a label that when clicked turns into a search box.
>* If you have to refresh 90% of the search results page anyway, why use React? Building and diffing a VirtualDOM isn't cheap*
Actually it can be as cheap as directly changing the DOM with JS. And diffing can be just a single op e.g. when using an immutable data structure for their always changing part of the data.
It's just a change done crudely, not even non-optimized, because it doesn't need that much optimization anyway.
The review of the QuickTime 4.0 player [1] at the User Interface Hall of Shame [2] should be required reading for user interface designers. Apple can't even follow their own guidelines, and keeps making the same mistakes (and worse), even today.
[1] http://hallofshame.gp.co.at/qtime.htm
[2] http://hallofshame.gp.co.at/index.php?mode=original
[1] http://hallofshame.gp.co.at/qtime.htm
[2] http://hallofshame.gp.co.at/index.php?mode=original
Thanks. A real trip into history. (I was about to say "memory lane" but I think most of these predate the point where I stared using computers a lot.)
I always thought "Don't make me think" was a bit of a UI reference that everyone should read.
This really grinds my gears: I was just on pluralsight but seems like 90% of websites have this problem where existing members are treated as 2nd class citizens. I executed a search for "UX" and found a class I waned to see. After clicking int it I was given 2 options "sign up" and "cancel". So as an existing paid customer my only options are "login" on upper right which then puts me on main member screen so I can perform that search again. or go through login process, and then hit the back button exact # of times to put me back a that search results page. Then if they didn't fuck that up i'd be able to go to that course and see it. And believe me, some websites manage to fuck that up too.
Other versions of this UX antipattern is where you try to get to the content and 99% of the screen is about signing up while 1% is the tiny "sign in" hyperlink. It causes much anxiety to actually locate it.
close cousin to this problem is lack of clear login area. Take Evernote for example, home screen has all of it's homepage taken with big photo, plan explanations, sign up form. But for existing users ? there's a tiny hamburger icon up top which you have to click to reveal the "sign in" link which will then finally give you the login form. This is so frustrating my only possible understanding is "f existing users since we already have their money"
Focus-stealing annoys me the most. Applications should never steal focus & should always open in the background.
Mobile offered a bit hope. First, the screens were to small to clutter with complicated GUIs. Second, you could substitute some visual controls with touch.
The piece by Maciej (http://idlewords.com/talks/website_obesity.htm) on page weight points out that a lot of sites have responded by developing desktop sites as if people are using them with touchscreens. I'm not sure that's a good idea.
I recently tried to get my mobile provider to set up data roaming while I was away from home. (You can't set up data roaming from home, for reasons that remain mysterious and unexplained.)
The fact I was using a mobile device didn't stop my provider's site from asking three times if I wanted to take part in a survey, or from displaying a floating "Would you like to chat?" dialog that was so big it literally covered a quarter of the mobile screen - and which moved to the same position whenever I try to scroll it out of the way.
It also didn't help my provider provide the right links to the right content.
Eventually I gave up. My gf already had data working, so we used her phone for everything.
The experience was impressively terrible.
Unfortunately if you don't have UI clue, mobile is just another way to get stuff wrong.
The fact I was using a mobile device didn't stop my provider's site from asking three times if I wanted to take part in a survey, or from displaying a floating "Would you like to chat?" dialog that was so big it literally covered a quarter of the mobile screen - and which moved to the same position whenever I try to scroll it out of the way.
It also didn't help my provider provide the right links to the right content.
Eventually I gave up. My gf already had data working, so we used her phone for everything.
The experience was impressively terrible.
Unfortunately if you don't have UI clue, mobile is just another way to get stuff wrong.
Try using an iphone (or spoofing your user agent as one). Often they don't test or care about any other phones, but iphone users get the VIP treatment.
Looking back through time for all the horrible UI sins cataloged in the opening paragraph, I'm pretty sure all of those were much more common in the past than they are now. Somehow, we actually have made those pieces of progress.
Except for cryptic icons, those seem on the rise again.
Except for cryptic icons, those seem on the rise again.
I tend to think that making a good UI is like writing a good technical document or good presentation slides. We should think UI as a kind of natural language. There could be some subjective guidelines, but I don't think there will ever be a definitive standard.
Does anyone have enough experience with Tk and REBOL why these should be exemplar as far as UI and layout is concerned?
I implemented a gui for SimCity in Tk, and at the time (~1993) it was the best user interface toolkit for X11 available, but only because the competition was Motif and its ilk. The reason it was relatively good in that context is that it had a built-in scripting language: TCL. (So did WINTERP, but that was XLisp + Motif, so Motif made it suck a hell of a lot more than XLisp made it win.)
As a scripting language, TCL is terribly designed (but beautifully implemented). But all that mattered at the time was that there was a scripting language that was present at the time the GUI tooklit, Tk, was designed (so they did not overlap and squabble about what they were trying to do) -- not that the scripting language itself was any good. (Personally, I'd MUCH rather be programming GUIs in PostScript than TCL, which is what I did before, for the previous port of SimCity to NeWS.)
The fact that TCL was an integral part of the design of Tk from day 1 made it possible to use the scripting language for what it was good for, instead of Tk trying to do that in a half-assed non-turing-complete way: to glue everything together and do all the dynamic symbolic stuff, binding events to handlers, creating objects, naming them, plugging them together. All with wonderfully flexible simplicity and generality. Instead of trying to wrap the X Toolkit Intrinsic's and Motif's lame overlapping and incoherent attempts at object oriented programming, configuration, skinning and event handling in C and .XDefaults files.
Here's a typical TCL file that creates an instance of a SimCity editor window (it's more complex than a typical less dynamic TCL gui, since it's capable of creating any number of independent editor window instances, which is why it uses a $win prefix for everything it creates):
https://github.com/SimHacker/micropolis/blob/master/micropol...
No matter how much you love Lisp, WINTERP was still just using it to wrap Motif, even though Motif was suffering from a terminal case of Greenspun's tenth rule, and contained its own ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Here's WINTERP:
http://nielsmayer.com/winterp/
As a scripting language, TCL is terribly designed (but beautifully implemented). But all that mattered at the time was that there was a scripting language that was present at the time the GUI tooklit, Tk, was designed (so they did not overlap and squabble about what they were trying to do) -- not that the scripting language itself was any good. (Personally, I'd MUCH rather be programming GUIs in PostScript than TCL, which is what I did before, for the previous port of SimCity to NeWS.)
The fact that TCL was an integral part of the design of Tk from day 1 made it possible to use the scripting language for what it was good for, instead of Tk trying to do that in a half-assed non-turing-complete way: to glue everything together and do all the dynamic symbolic stuff, binding events to handlers, creating objects, naming them, plugging them together. All with wonderfully flexible simplicity and generality. Instead of trying to wrap the X Toolkit Intrinsic's and Motif's lame overlapping and incoherent attempts at object oriented programming, configuration, skinning and event handling in C and .XDefaults files.
Here's a typical TCL file that creates an instance of a SimCity editor window (it's more complex than a typical less dynamic TCL gui, since it's capable of creating any number of independent editor window instances, which is why it uses a $win prefix for everything it creates):
https://github.com/SimHacker/micropolis/blob/master/micropol...
No matter how much you love Lisp, WINTERP was still just using it to wrap Motif, even though Motif was suffering from a terminal case of Greenspun's tenth rule, and contained its own ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Here's WINTERP:
http://nielsmayer.com/winterp/
Thanks again for your incredible work on SimCity.
I was wondering the same thing. Reading the other answers, it seems like the reason the author thinks they're superior is that he can design interfaces using only code. (Not sure if that's the author's point or just the posters here.) I've had to use the apps that result from developers designing interfaces in code and I've had to read some of the code to do it, and in my experience it was all suboptimal.
With a tool like Interface Builder (which I'm not saying is good), at least it gives you guides for the standard places that elements should line up with each other. Sometimes you want the baseline of the text of various elements to align. Sometimes you want to ensure the same padding around elements. All of that typically goes out the window when interfaces are designed via code, in my experience.
Furthermore, the author seems to advocate that UIs should be disconnected from events. I can't think of a useful UI element that isn't tied to some event. I'd love to learn more about what they mean, but right now, it's not ringing true to me.
With a tool like Interface Builder (which I'm not saying is good), at least it gives you guides for the standard places that elements should line up with each other. Sometimes you want the baseline of the text of various elements to align. Sometimes you want to ensure the same padding around elements. All of that typically goes out the window when interfaces are designed via code, in my experience.
Furthermore, the author seems to advocate that UIs should be disconnected from events. I can't think of a useful UI element that isn't tied to some event. I'd love to learn more about what they mean, but right now, it's not ringing true to me.
>> design interfaces using only code
The lines are blurred in Rebol because code is data and data is code.
>> the author seems to advocate that UIs should be disconnected from events
I don't think the author is advocating this because both TCL/TK & Rebol View rely on events.
The lines are blurred in Rebol because code is data and data is code.
>> the author seems to advocate that UIs should be disconnected from events
I don't think the author is advocating this because both TCL/TK & Rebol View rely on events.
I've only had limited experience of Rebol View (VID & R3-GUI) so I don't feel qualified enough to give you a clear answer.
However I can provide you with some HN comments that contain Rebol GUI code that I've posted here in the past:
* https://news.ycombinator.com/item?id=7069311
* https://news.ycombinator.com/item?id=8624722
* https://news.ycombinator.com/item?id=9570049
NB. If you follow the thread up in the first link you'll find GUI comparisons with TCL & other languages.
You may find more insight into the authors mind from snippets found in previous posts:
http://prog21.dadgum.com/159.html - "The best attempt I've seen is the UI description sub-language of REBOL. Creating a basic window with labeled buttons is a one-liner. Clearly all wasn't perfect in REBOL-ville, as a burst of excitement in the late 1990s was tempered with a long period of inactivity, and some features of the language never quite lived up to their initial promises.
These days HTML is the most reasonable approach to anything involving fonts and images and interaction. It's not as beautifully direct as REBOL, and being trapped in a browser is somewhere between limiting and annoying, but the visual toolkit is there, and it's ubiquitous. (For the record, I would have solved the "list all the filenames..." problem by generating HTML, but firing up a browser to display the result is a heavy-handed solution.)"
http://prog21.dadgum.com/66.html - "A handful of language designers have tried to make GUI programming as easy as traditional programming. The Tk library for TCL, which is still the foundation for Python's out-of-the-box IDE, allows basic UI creation with simple, declarative statements. REBOL is a more recent incarnation of the same idea, that sample code involving windows and user input and graphics should be a handful of lines, not multiple pages of wxWindows fussing. I wish more people were working on such things."
However I can provide you with some HN comments that contain Rebol GUI code that I've posted here in the past:
* https://news.ycombinator.com/item?id=7069311
* https://news.ycombinator.com/item?id=8624722
* https://news.ycombinator.com/item?id=9570049
NB. If you follow the thread up in the first link you'll find GUI comparisons with TCL & other languages.
You may find more insight into the authors mind from snippets found in previous posts:
http://prog21.dadgum.com/159.html - "The best attempt I've seen is the UI description sub-language of REBOL. Creating a basic window with labeled buttons is a one-liner. Clearly all wasn't perfect in REBOL-ville, as a burst of excitement in the late 1990s was tempered with a long period of inactivity, and some features of the language never quite lived up to their initial promises.
These days HTML is the most reasonable approach to anything involving fonts and images and interaction. It's not as beautifully direct as REBOL, and being trapped in a browser is somewhere between limiting and annoying, but the visual toolkit is there, and it's ubiquitous. (For the record, I would have solved the "list all the filenames..." problem by generating HTML, but firing up a browser to display the result is a heavy-handed solution.)"
http://prog21.dadgum.com/66.html - "A handful of language designers have tried to make GUI programming as easy as traditional programming. The Tk library for TCL, which is still the foundation for Python's out-of-the-box IDE, allows basic UI creation with simple, declarative statements. REBOL is a more recent incarnation of the same idea, that sample code involving windows and user input and graphics should be a handful of lines, not multiple pages of wxWindows fussing. I wish more people were working on such things."
"Set of Standard Resources"
Check out Material Design by google - its been a lifesaver to me who is from a very technical background. Best part is with very little work you can really impress your bosses !
Good Luck
Check out Material Design by google - its been a lifesaver to me who is from a very technical background. Best part is with very little work you can really impress your bosses !
Good Luck
Material Design is just like Apple's guidelines. It's great for helping to create something that looks uniformly designed and not a hodge podge of UI gimmicks, helping design-ignorant coders create something that looks nice, and as you say it's easy to get management buy in, but is it actually good? Will following it actually reduce your count of UI mistakes? Personally I don't like it at all, and I've had many complaints, both functional and from personal preference, with Google's design changes over the last few years.
I agree.
But I do not have the time to go back and do another degree on design. Try convincing people with money to shell out extra for someone with good design experience.
I guess once we have millions of customers we might have to think about it - but small companies without much resources its hard to justify spending a lot of resources on good design.
But I do not have the time to go back and do another degree on design. Try convincing people with money to shell out extra for someone with good design experience.
I guess once we have millions of customers we might have to think about it - but small companies without much resources its hard to justify spending a lot of resources on good design.
Good design == lower churn, higher LTV.
Material design is great but I see apps that don't need it implement it a lot. Not every app needs a FAB, or a card ui.
IANAUIE (guess what that stands for. ;) )
Yet I am primarily responsible for the UI on the product on which I'm writing code. I started out with a bland and crappy interface expecting the client to look at that and provide their branding and suggestions for how it should work. Most UI elements are their default colors. Style? Please, I'm an engineer! I thought at some point they would provide a detailed list of requirements to provide a decent UI. I thought wrong.
I have done what I could to provide an easy to use intuitive interface. Unfortunately what is intuitive for me is not going to be intuitive to others.
Eventually I did receive some usability suggestions. I'm not sure they were carefully thought out. One point I would have suggested aligned with a marketing video on their web site but did not match their requirement.
Until producers of products of products care about the appearance and usability of their products, these things are not likely to get better.
As for my own feelings about UI, there are a few beliefs I hold deeply.
If a UI can model some sort of physical reality, it is going to be easier to use. If not a physical reality, at the least a consistent model.
I hate UIs that change depending on state. Disappearing menu items or screen elements drive me nuts. Think of shifting sands.
Discoverability is something that concerns me. Much of the S/W I work with has options or key shortcuts that I never know about because I'm too lazy to read through the manual. I do not know the solution to this, but I do know the problem.
Yet I am primarily responsible for the UI on the product on which I'm writing code. I started out with a bland and crappy interface expecting the client to look at that and provide their branding and suggestions for how it should work. Most UI elements are their default colors. Style? Please, I'm an engineer! I thought at some point they would provide a detailed list of requirements to provide a decent UI. I thought wrong.
I have done what I could to provide an easy to use intuitive interface. Unfortunately what is intuitive for me is not going to be intuitive to others.
Eventually I did receive some usability suggestions. I'm not sure they were carefully thought out. One point I would have suggested aligned with a marketing video on their web site but did not match their requirement.
Until producers of products of products care about the appearance and usability of their products, these things are not likely to get better.
As for my own feelings about UI, there are a few beliefs I hold deeply.
If a UI can model some sort of physical reality, it is going to be easier to use. If not a physical reality, at the least a consistent model.
I hate UIs that change depending on state. Disappearing menu items or screen elements drive me nuts. Think of shifting sands.
Discoverability is something that concerns me. Much of the S/W I work with has options or key shortcuts that I never know about because I'm too lazy to read through the manual. I do not know the solution to this, but I do know the problem.
was hoping you were going to give a standard resource where I can find alternatives for common bad designs
Check out "About Face" by Alan Cooper et al.
A well respected interaction designer was so kind to give me her 1st edition many years ago and I still find myself coming back to it regularly.
New and updated 4th edition:
https://en.wikipedia.org/wiki/Special:BookSources/9781118766...
A well respected interaction designer was so kind to give me her 1st edition many years ago and I still find myself coming back to it regularly.
New and updated 4th edition:
https://en.wikipedia.org/wiki/Special:BookSources/9781118766...
I had bought and read the 1st edition of About Face years ago. Thought it good generally. Might not have understood everything in it at the time. I remember him talking about "affordances". One point I thought was good, was his idea for a scroll bar with both the arrow heads at the same end of the bar, instead of at opposite ends. This saves you from having to move your mouse from one end of the bar to the other, to reverse scroll direction (since you have to click on either the up/left or down/right heads).
Like this (for a horizontal scroll bar):
<||> =============================
instead of this:
<|==============================|>
Cool. Later I heard from someone that some OS/GUI platform actually has his improved version - I forget which.
Like this (for a horizontal scroll bar):
<||> =============================
instead of this:
<|==============================|>
Cool. Later I heard from someone that some OS/GUI platform actually has his improved version - I forget which.
IIRC OSX had it at some point.
I'll second this recommendation. I picked up the 4th edition a few months ago.
It's a great book, but also a very long read. As a developer who is interested in developing usable apps, but not in being a full-time UX designer, I've found that I've been able to pick and choose the bits of the book that are relevant to the tasks I'm working on. It helps if you've read the introductory bits, but later on it has sections about web, desktop, mobile, etc. that are useful on their own. It's almost like having several books in one.
It's a great book, but also a very long read. As a developer who is interested in developing usable apps, but not in being a full-time UX designer, I've found that I've been able to pick and choose the bits of the book that are relevant to the tasks I'm working on. It helps if you've read the introductory bits, but later on it has sections about web, desktop, mobile, etc. that are useful on their own. It's almost like having several books in one.
I tend to rely on the Apple's UI guidelines. They have many hints that are applicable even for non-Apple apps. I remember Apple had a similar thing already back in 80s, which I found amazing.
https://developer.apple.com/library/mac/documentation/UserEx...
https://developer.apple.com/library/mac/documentation/UserEx...
I tend to rely on the Apple's UI guidelines.
Please explain the OS X iTunes UI to me. It's beyond awful, and it seems to get worse with every update.
If there were a death penalty for bad UI designers, and I were in charge of implementing it, I'd have the iTunes designers first against the wall.
My guess is that iTunes doesn't follow Apple's guidelines?
Please explain the OS X iTunes UI to me. It's beyond awful, and it seems to get worse with every update.
If there were a death penalty for bad UI designers, and I were in charge of implementing it, I'd have the iTunes designers first against the wall.
My guess is that iTunes doesn't follow Apple's guidelines?
Over time, iTunes has gotten very cryptic and undiscoverable in its features. I really wonder how users who're not well versed with computers even do anything with iTunes. Or maybe they don't even install it in the first place. :)
Cycle through apps using command-tab. Cycle through a few times. See how it works.
Now cycle through app-windows with command-` and see how that works .. completely differently.[1]
So yes, even the wizards can get it wrong[2].
[1] command-tab has a proper "memory" allowing you to command-tab back and forth quickly between the two most recent apps. command-` is just ... weird. It sort of preserves sequence ... until you let go ? and then reverses sequence ... or something ? 8 years into OSX and I still am not sure what the algorithm is.
[2] Not saying either is the right one - but they are both different, so one of them (as far as apple is concerned) is wrong.
Now cycle through app-windows with command-` and see how that works .. completely differently.[1]
So yes, even the wizards can get it wrong[2].
[1] command-tab has a proper "memory" allowing you to command-tab back and forth quickly between the two most recent apps. command-` is just ... weird. It sort of preserves sequence ... until you let go ? and then reverses sequence ... or something ? 8 years into OSX and I still am not sure what the algorithm is.
[2] Not saying either is the right one - but they are both different, so one of them (as far as apple is concerned) is wrong.
>Not saying either is the right one - but they are both different, so one of them (as far as apple is concerned) is wrong.
Or maybe each of them is appropriate for the (different) tasks it has to do?
Or maybe each of them is appropriate for the (different) tasks it has to do?
Ditto. Sadly, this got posted three times to HN already and hit my twitter feed without seeing anyone say "you're wrong, there's a book everyone should read!"
At this point, my hopes are low.
At this point, my hopes are low.
The most annoying "focus stealing" for me is what (some?) browsers do when actions initiated earlier on (like clicking on a bookmark that doesn't appear to load) finish while I'm typing in the address bar: they just overwrite what I typed with the new URL, or cause focus loss on the address bar so I suddenly type "nowhere". So frustrating...
IM clients that steal focus when a new conversation begins are fantastic about this. More than a few times a coworker has gotten half a line of random code as a response when they try to ask me a question over Sametime.
I think everyone knows that non-modal dialogs, live previews and obvious icons are better, but they're also harder to do.
My biggest complaint is regarding web sites/applications that basically ignore the existence of keyboards. Some of this comes from the UI toolkit that they're using, but it's pretty egregious. For just "brochure" web sites, it's not that big of a deal, but some are really, really bad about tabbing order, or tabbing at all, and certain controls don't work correctly without the mouse/touch.
I'd say bootstrap and the likes are killing the need for a fresh look at design by offering templates. For me the savior has been Basecamp's design. Always made sense and looked great.
The fact that those are the faults you think are the worst shows how entrenched bad UX is.
E.g. drop down menus are a fail.
If you read Raskin's "The Humane Interface" you can see a whole host more.
Raskin, Jef 2000.The Humane Interface, Addison-Wesley ISBN 0-201-37937-6
E.g. drop down menus are a fail.
If you read Raskin's "The Humane Interface" you can see a whole host more.
Raskin, Jef 2000.The Humane Interface, Addison-Wesley ISBN 0-201-37937-6
>If you read Raskin's "The Humane Interface" you can see a whole host more
Well, Raskin also has some bizarro ideas about what a good UI should be, and his later attempts of realizing one is not anything most people would want to use.
Well, Raskin also has some bizarro ideas about what a good UI should be, and his later attempts of realizing one is not anything most people would want to use.
I use Acme text editor which uses some of Raskin's ideas
It is the best I have ever used
https://en.wikipedia.org/wiki/Acme_%28text_editor%29
https://en.wikipedia.org/wiki/Acme_%28text_editor%29
I would argue this is working as intended. The advantage of background notification rather than modal is that the user gets a choice. The user could very well decide that your EXTRA SUPER URGENT notification is, in fact, unimportant, and this right here is a perfect example.
No, I don't care if your bullshit app that I've opened a grand total of twice needs a 200 MB update. If anything, there should be an option to force old notification circles to go away after two weeks or so except for legitimately important apps like email and messaging.