Minimizing Complexity In User Interfaces • Hacker News Board

Re: Minimizing Complexity In User Interfaces

#31

Post by cschneid » Thu, Oct 08, 2009, 2:30 PM UTC

thunk wrote: post #30

Yeah, emacs and vim would never have gotten where they are if it weren't for their simple, intuitive interfaces. The Simple UI camp is wrong: It's not complexity you want to minimize in a UI -- muscle memory will take care of that -- it's time and exertion. Reminds me of: http://www.theonion.com/content/video/apple_introduces_revol...

I disagree in a large part due to different use cases. Developers often "live" in their editor, using it all day. Because of that, a non-obvious interface is ok, if the benefit is faster processing. The same reasoning applies to the old school text interfaces for insurance agents. They can fly through it and get you a quote very quickly.

But, I know that I don't use my time tracker application often enough to allow it to become super cluttered and non-obvious. Same with my bank's website.

Different use models require different approaches to usability.

Re: Minimizing Complexity In User Interfaces

#32

Post by berntb » Thu, Oct 08, 2009, 2:35 PM UTC

ahoyhere wrote: post #27

berntb wrote: post #24

Earlier quoted context omitted.

Let me limit this to web applications. To me this discussion sounds like an argument for user controlled scripting languages in web applications. This is needed since web applications which use lots of Javascript can't be automated by normal web scraping libraries with no Javascript/DOM emulators (they support cookies, etc so they can do sessions etc). Something like the classic Applescript, for user control. (Or may…

There are a few problems with this. 1. No one will do it. 2. Even people who do know how to program have a special aversion to JavaScript, especially. 3. Almost no one is equipped (or willing to invest the time/effort) to analyze their work and come up with a process that is best for them. A typical person is about as self-aware as a box of rocks. Even particularly smart, savvy, successful people. It takes a lot of w…

You and 'toadpipe' are probably correct. I'll argue the point anyway, to see if it could be made to work:

Consider that the scripts would run on the web server. That means they would be published and used by other users... (After a bit of analysis, so they don't do anything destructive.)

And charge money from users that really want their scripts to be private.

Just make certain that there is a script language defined for the web app framework -- and an extensible object model for the local web site's data. (Again, Applescript. But not that syntax!)

Re: Minimizing Complexity In User Interfaces

#33

Post by ahoyhere » Thu, Oct 08, 2009, 2:55 PM UTC

berntb wrote: post #32

ahoyhere wrote: post #27

Earlier quoted context omitted.

There are a few problems with this. 1. No one will do it. 2. Even people who do know how to program have a special aversion to JavaScript, especially. 3. Almost no one is equipped (or willing to invest the time/effort) to analyze their work and come up with a process that is best for them. A typical person is about as self-aware as a box of rocks. Even particularly smart, savvy, successful people. It takes a lot of w…

You and 'toadpipe' are probably correct. I'll argue the point anyway, to see if it could be made to work: Consider that the scripts would run on the web server . That means they would be published and used by other users... (After a bit of analysis, so they don't do anything destructive.) And charge money from users that really want their scripts to be private. Just make certain that there is a script language define…

Then the question should be:

Why?

Re: Minimizing Complexity In User Interfaces

#34

Post by berntb » Thu, Oct 08, 2009, 4:16 PM UTC

ahoyhere wrote: post #33

berntb wrote: post #32

Earlier quoted context omitted.

You and 'toadpipe' are probably correct. I'll argue the point anyway, to see if it could be made to work: Consider that the scripts would run on the web server . That means they would be published and used by other users... (After a bit of analysis, so they don't do anything destructive.) And charge money from users that really want their scripts to be private. Just make certain that there is a script language define…

Then the question should be: Why?

I thought that was obvious from the starting point. Lacking features is a problem for large subsets of users.

This would be a way to add functionality (and possibly to integrate with other services, so you e.g. could do "legal" XSS.)

Re: Minimizing Complexity In User Interfaces

#35

Post by fnid » Thu, Oct 08, 2009, 5:09 PM UTC

The illusion here is that simple/less complex apps are better. But the reality is that more simple apps with fewer features means the end user needs more apps to manage their business or their lives.

Your invoicing app may be simple and let you send an invoice, but does it integrate with your time entry system? Wouldn't a time entry system that does invoicing or an invoicing system that also does time entry be better than two disparate apps that do one or the other? Who wants to waste time entering the same information twice? Making data entry mistakes? Flipping between different apps, usernames, passwords...

The problem with the simple is better line of thinking is that it actually complicates the business life. Multiple accounts at multiple sites. Multiple payments to multiple vendors. Different user interfaces to learn at each site. Different ways of doing things. Maybe the enter key over there submits the form, but it goes to another field somewhere else.

All these separate systems are really just features of a business management suite and I'd rather keep all my stuff in one place than have 15 accounts at different locations to do one thing. If I can pay $50 a month for a system I can customize to do what all these 15 sites do for $10-99/mo I'd be a much happier customer.