I think that you hit upon a very important aspect of good design -- that it is consistent throughout the user's experience. If even one part of the experience is less than satisfactory, then the designers have failed. The user walks away with a bad taste in their mouth.
I'd love to hear Josh's thoughts once JavaOne is over. Best of luck! :) --Ryan On Thu, May 28, 2009 at 8:49 PM, Reinier Zwitserloot <reini...@gmail.com>wrote: > > Here's a fine example of how clearly somebody wasn't even thinking > straight. This is linux, doing a major update in ubuntu. Just a few > things sprang to mind: > > The theme: Every so often I get a dialog box that tells me that I've > changed some settings file and now apt-get doesn't know what to do; > replace, keep the old one, attempt to merge it. This dialog is so > ridiculously insanely stupid that I don't get why microsoft isn't > showing this to the world and going: TADAAAAA - linux is an amateur > toy that doesn't deserve to play in the real world. It's that dumb. > We're using a gui based updater here that's just a light frontend on > top of apt-get, which is a package manager that basically knows > dependencies and works it all out for you, and can even update > packages by taking down the service, replacing the files, integrate > whatever changes to the settings files are required, download and > install all dependencies, then take the service back up. That's quite > a feat, and apt-get is really cool. It's probably the principal reason > why debian is cool, and ubuntu ate redhat's lunch (redhat uses rpm, > which can't do all that). Now that you know, let's move on to how this > fantastic tool turns into unbelievable suck, just because of bad user > interface design. Compared to the mind boggling effort that goes into > maintaining all those packages, keeping a fleet of mirrors running to > serve all of them, and the effort that went into the technical design > and development of the apt system, this is small fry: > > [ simple stuff that's easy to fix and should assault your senses > immediately. This isn't the kind of Joe Nuxoll style thinking out of > the box stuff, just general: We need to make sure our user interfaces > aren't explicitly out to shoot the user in the foot] > > A. it's an enormous dialog box that's totally empty, except for 1 > dropdown box. Anyone remember the microsoft shut down dialog drama? > the entire screen as real estate, and you hide the important bits in a > -drop down box-, that you have to click. WTF? Dropdown box contains > the same 5 choices every time. Opening it just opens it across a sea > of grey. If you're thinking of user interface design even a little, > the first time you as a developer see this dialog box, you should file > a 'critical' bug or fix it then and there. You don't let piss like > that go out into the world, period. > > B. One of the times the dialog box popped up it didn't even have a > sensible file name. I had absolutely no idea what I was supposed to > 'keep', 'replace', 'integrate'. > > > Now lets dig deeper. We know that apt more or less forces this > situation, if you have any experience with the text output of the apt- > get tool. But, even with the way apt works, we can do a better job, > even if we're still not in Joe Nuxoll think: > > C. Give me the full path to the settings file, show the diff between > the old and the new, and offer me an option to manually integrate the > files. > > And now for the big whammy, let's redesign this entire thing so that > it's actually, you know, usable by a mere mortal: > > D. There's such a thing as file system hooks. Apple uses it in place > of a registry; all applications have a file in them that explains > which files they can open, and everything you put an app on your > harddisk, a system hook reads this information and makes sure that, > when you right click on such a file, that app shows up in the 'open > with...' dialog. There's neither a registry (windows) nor a big > settings file (linux) to worry about. When you delete the app (there > are no uninstallers on os x, just delete it), the file system hook > removes that app from open with lists. You can apply the same tactic > to settings files: *ANYTIME* I mess with a settings file, apt should > be called so that it can inspect what I just did, see if it can > automatically integrate that change with a possible future update, and > if not, back up the previous version, and send me a mail (or better > yet, if we're on a GUI, show as I try to save it) how I can fix it or > where I can edit it so that it does integrate properly. Note that all > major linux file systems offer this feature. > > NB: For many apt-get installed tools, the settings file for that tool > is managed by apt, but it 'includes' a special file that you can > safely edit without setting yourself up for future pain. However, most > manuals on configuring the tool aren't debian/ubuntu aware and point > you to the file you're not actually supposed to edit. Often there are > some remarks in there by the debian package maintainer that you're not > supposed to edit this file, but, yeah, as if I'm going to read all of > those! How perfect would it be that, on saving, apt-get runs in the > background, automatically diffs my changes, and tries to automatically > move them to the right properties file, -or-, mails me this plan so I > can confirm or deny it. > > E. Upgrading debian or ubuntu takes a day or two. That's because for > every conflict and settings problem you get a dialog box. I'm not > going to sit and stare at my computer for the 1 or 2 hours total > runtime it takes to process all updates, so what ends up happening is > that it just sits there, idle, showing a dialog box, and every hour or > 3 I check in, turning the process into a long and painful process that > I loathe. There's no excuse here: the gui tool (and probably apt-get > itself) should figure out all conflicts beforehand, and toss all > dialog boxes my way BEFORE starting the actual process of downloading > and replacing things. This also allows me to hit 'cancel' midway > through, whereas with current apt-get, you can't really do that > halfway in. > > You could take that opportunity to rethink the design of your dialog > boxes, and for e.g. settings files, show a table, with checkboxes that > you can quickly mark as replace/keep/integrate, along with e.g. double > clicking on any entry to show a diff editor so I can manually fix it. > > > > Is this easy? Well, I just thought of all of that in the span of 15 > minutes, and compared to the effort behind the mirrors and apt itself, > developing all of that is indeed easy. And yet, its the difference > between 'utterly useless piece of tripe that makes me want to throw my > house server out the window every time I dare update my ubuntu', and > 'so awesome I'd shit bricks - and I'd tell all my friends too'. > > On May 29, 3:49 am, Michael Neale <michael.ne...@gmail.com> wrote: > > Well good luck with everything for JavaOne ! And I hope you can post > > more on this subject in the future - just resurrect it when you have > > some time ! > > > > On May 29, 11:47 am, Joshua Marinacci <jos...@gmail.com> wrote: > > > > > It sucks that this thread is going on right now during JavaOne prep. > > > I'd love to join in. I'll just say this really quick: > > > > > Yes, UI design (and visual design in general) is an art. But there is > > > method to the madness. There are rules and guidelines. There are > > > things you can learn and apply in a rigorous manner. And yes, it's > > > even possible for engineers to learn the basics of design (UI and > > > otherwise). I hope to explore this more after JavaOne. In the > > > meantime, stay tuned for some cool stuff next week and feel free to > > > send me your questions on anything. > > > > > - Josh > > > > > On May 27, 2009, at 8:29 PM, Ryan Waterer wrote: > > > > > > The tools help streamline parts of code that can be streamlined. > > > > > > "Beauty is in the eye of the beholder." What is intuitive to one > > > > person can be cumbersome and clunky to another, or too simple and > > > > limiting to someone else. From my understanding, we want to design > > > > to a certain demographic, and have it be as easy to use for that > > > > demographic. > > > > > > I believe that UI is art. Just like art, you can teach design > > > > principles, concepts and techniques. Just like with art, some > > > > people with be naturally gifted, and understand ways to present the > > > > information in an effective manner. I also believe that there are > > > > some people who just "get" server side logic extremely well; it > > > > comes naturally. We can just look at Dick and Joe for examples of > > > > both types. This doesn't mean that Dick can't learn to be extremely > > > > > good at designing UI. > > > > > > I agree with Michael in that doing a "good" UI is often more > > > > expensive. I think that it's the least understood, and put off > > > > until the last in most cases. As Joe has argued in the past, this > > > > is extremely bad for a product. I'll go a step further -- I think > > > > > that bad UI is more damaging and costly to a product than a poorly > > > > written back-end system. > > > > > > While I do enjoy playing computer and console games, they are also a > > > > > fantastic study of UI design and different approaches. While the > > > > complexity of the game varies, a good design does a great job of > > > > hiding the complexity and helps with the immersion of the game. A > > > > UI that "gets in the way", and forces the user to break immersion is > > > > > clunky and poorly designed. > > > > > > A different look is the new nintendo system (let's ignore all > > > > discussions on the value of the system, the gimmickery, etc). They > > > > > took a piece of hardware that is difficult to pick up and use and > > > > transformed it into something that most everyone recognizes and > > > > understands how to use -- a TV remote control. Like my comment > > > > above, Nintendo made it so that the "UI" didn't interfere with what > > > > the user wanted to accomplish -- play games. > > > > > > Ultimately, I think that is a good definition of a good UI or a good > > > > > design. Can the user do what they want to do in an easy, efficient > > > > > manner? > > > > > > On Wed, May 27, 2009 at 8:47 PM, Michael Neale < > michael.ne...@gmail.com > > > > > wrote: > > > > > > good points - and I agree with Mark - change is in fact good, nothing > > > > to be allergic to. > > > > > > I think the important point to me was that is very very very hard, > and > > > > very very important. I also wish I was better at it - partly that is > > > > practice and study, but I think the bigger thing is facing up to the > > > > fact that this is important and hard - and getting it right will give > > > > you a competitive advantage (a la apple) versus the way the status > quo > > > > views it: a detail which is just an annoying cost. > > > > > > Unfortunately UI design isn't as respected, at least in some circles, > > > > so its a tough battle. > > > > I am glad there are like minded people here (and Joe's influence is > > > > appreciated). > > > > > > The worst thing: doing it right is expensive, so, so expensive, and > no > > > > one wants to hear that. In fact as we use tighter tools and languages > > > > which compress the cost in the "other layers", it makes a quality UI > > > > seem proportionally very expensive - I have no idea what to do or > > > > think about that problem. > > > > > > On May 28, 11:00 am, Reinier Zwitserloot <reini...@gmail.com> wrote: > > > > > Same here; I disagree with the notion that its an art and can't be > > > > > learned well if you don't have the knack for it. > > > > > > > I think that most software developers/companies just don't put in > > > > the > > > > > effort. No, scratch that - they don't even acknowledge that such a > > > > > thing as design exists. > > > > > > > if you haven't the first clue on user interaction design, and you > > > > > still start off with: I will design the user interaction first, and > > > > > then I'll build whatever I need to make it work, even if this is > > > > > wildly different from how things work under the hood - then you'll > > > > > get > > > > > a long way already. Sure, getting it -perfect-, that may be an art > > > > > form, but what isn't? (I'm channeling Joe Nuxoll here a bit; he's > > > > very > > > > > much against designing the interface of an app to mirror the > > > > technical > > > > > implementation, and I think having an innate alarm bell in your > head > > > > > whenever you do that is a good thing). > > > > > > > Apple on the other hand takes this so seriously, its practically > > > > their > > > > > corporate mantra. They still get it wrong plenty of times - even > > > > apple > > > > > isn't perfect, but at least they acknowledge that the world is > > > > > supposed to work User interface first - everything else later. > > > > > > > Simple examples: > > > > > > > Instead of letting your web app write dates like 'May 1st, 2009 > > > > > 12:14', generate '5 hours ago'. That's what people really want. Of > > > > > course the database stores timestamps and not a continually > updating > > > > > 'X seconds ago' - but the fact that the database stores timestamps > > > > > does not mean you need to render them as such. Just because Samba > > > > has > > > > > 500 settings doesn't mean you need to have a settings dialog with > > > > all > > > > > of that; instead, creating some oft employed defaults, and let the > > > > > user pick one of those. If you want to be linuxy about it, over an > > > > > 'advanced...' button that lets you edit this to the exacting specs > > > > > that text configuration of Samba allows - I don't think apple, or > > > > the > > > > > right spirit for interface design, is against giving users that > kind > > > > > of power if they really want it. The important point is that you > > > > don't > > > > > make things needlessly complicated just because you're not willing > > > > > to > > > > > think beyond the road thats paved out for you due to technical > > > > > circumstances. This is of course a lot harder, but then, making > good > > > > > stuff generally isn't. > > > > > > > On May 28, 2:13 am, Mark Hibberd <mthibb...@gmail.com> wrote: > > > > > > > > On Thu, May 28, 2009 at 9:42 AM, Michael Neale > > > > <michael.ne...@gmail.com> wrote: > > > > > > > > > well replace intuitive with cohesive and consistent etc... do > > > > you > > > > > > > agree with the gist of it then? > > > > > > > > Yeh I would. I definitely agree it is underrated, both how > > > > difficult > > > > > > and how important it is to get UI right. I just think the > article > > > > > > overlooks the point (maybe intentionally) that not every user or > > > > > user > > > > > > base is the same and that it is pretty easy to find fault with a > > > > > > system/ui when it is not built to the purpose or audience that > > > > you are > > > > > > applying it to. > > > > > > > > I think my position can be summarized as: Good UIs are not > > > > universal, > > > > > > even if the principles that guide an effective UI are (and with > > > > a few > > > > > > exceptions, they are). > > > > > > > > > I so wish I had the skills that is described there, I have an > > > > enormous > > > > > > > amount of respect for those who are able to get it right (I > > > > don't > > > > > > > agree that you *can't* learn them), and desperately try to > > > > learn more > > > > > > > myself, and practice... > > > > > > > > > I think you could stretch user interface to include major > > > > apis, if you > > > > > > > kind of tilt your head a bit... but still, I think its really > > > > the most > > > > > > > important thing today. > > > > > > > > APIs definitely need to be classed as UI, and treated with a > > > > level of > > > > > > respect that is often lacking. There are definite skills that > > > > apply > > > > > > across the board to UI, be it API or GUI, like making it easy to > > > > > do > > > > > > the right thing, making it hard (impossible?) to do the wrong > > > > thing. > > > > > > > > One interesting thing is that people feel it is generally > > > > acceptable > > > > > > to evolve a GUI but not a programmatic API. I think everyone > > > > needs to > > > > > > get over that. Change is awesome. > > > > > > > > Mark. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
