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 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 <[email protected] > > > > 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 <[email protected]> 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 <[email protected]> wrote: > > > > > > On Thu, May 28, 2009 at 9:42 AM, Michael Neale > > > <[email protected]> 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 [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 -~----------~----~----~----~------~----~------~--~---
