Part of the art of UI design is knowing when to listen to your users *and* when to ignore them. Most of the many UI flaws in Windows remain not because Microsoft's designers are unaware of them. :)
On May 28, 2009, at 9:52 PM, Michael Neale wrote: > > OH, also, and when you fix something, there will be the 10 angry > emails from people who don't like it now, who liked it then, or don't > like change, or just like to write angry emails. > > You know when Toyota changed the Landcruiser from having a basic metal > dashboard to a modern one they got death threats ! > > On May 29, 1:09 pm, Ryan Waterer <[email protected]> wrote: >> 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 >> <[email protected]>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 <[email protected]> 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 <[email protected]> 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 >> >> ... >> >> read more ยป > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
