fifty times fifty thousand
Application programming is a most interesting journey.
[For me at least] Designing and executing the functioning code of your application, the skeleton, limbs and muscle if you will, is, while perhaps not easy from a technical perspective, a piece of cake insofar as you know what you want and how you want to achieve it. It may take developing new skills, asking for help, years of your time and what have you, but there is a clear goal at which to kick.
Sit down to design and execute the UI* to your application - the skin - however, and the river doeth often run dry.
Suddenly there are external considerations.
The first hurdle is always the standards, recommended or enforced. These have, in another life, almost driven me to lunacy. In my current workspace, though, I'm not so troubled as they often, or at least sometimes, make sense and are, for the most part, useful in bringing about a unified and accessible interface layer for the user. If you work with a treat of a platform like Apple OS X it's about as easy as can be, perhaps even rewarding.
The second hurdle, though, is the real blocker: personal taste versus mass market accessibility.
I know what I want in an app'. I want speedy interfacing with the relevant components, no clutter and an emphasis on key-strokes and modifiers to execute commands. The problem, though, is the question of whether that suits everyone else, namely, your market. You are writing this for everyone, right?
Taken a look at Word lately? Have a look at the freaking insane number of menu bars and icons. Have you ever even used these? Probably not because you're a clever, blogging, power user. But do you think anyone uses them? It can't be denied there's a possibility they do. The logic then is that if someone might need to click on a disk icon, instead of pressing CTRL-S, then perhaps we should leave it there.
So while you can take this very brutish approach to designing your UI and say well, I'm not going to support this. It's plainly clear what you need to do in my application without this superfluous dogpile and I refuse to cater to the minority of users who want it. you're ignoring a potential fly in your ointment.
What about people with disabilities who rely on aiming for that one icon to save their document? What about those people who genuinely struggle to see their way through the maze of menus to find Page Setup or Styles? You know they're out there. Deep down you know it.
And so you sit down to design your UI and these things come to mind. I went up and down on this roller coaster this evening while working on a draft of a UI for an app' I am working on. The resolution was that I am going to document well, have a decent tutorial and keep my UI minimal. If ever this thing gets out there and I receive a pleasant email from a user telling me that they could really use a little help on the UI-front I've promised myself I'll look into it.
After all, #ifdef LITTLE_HELP should do it.
* User Interface, for the non-software folk.
[For me at least] Designing and executing the functioning code of your application, the skeleton, limbs and muscle if you will, is, while perhaps not easy from a technical perspective, a piece of cake insofar as you know what you want and how you want to achieve it. It may take developing new skills, asking for help, years of your time and what have you, but there is a clear goal at which to kick.
Sit down to design and execute the UI* to your application - the skin - however, and the river doeth often run dry.
Suddenly there are external considerations.
The first hurdle is always the standards, recommended or enforced. These have, in another life, almost driven me to lunacy. In my current workspace, though, I'm not so troubled as they often, or at least sometimes, make sense and are, for the most part, useful in bringing about a unified and accessible interface layer for the user. If you work with a treat of a platform like Apple OS X it's about as easy as can be, perhaps even rewarding.
The second hurdle, though, is the real blocker: personal taste versus mass market accessibility.
I know what I want in an app'. I want speedy interfacing with the relevant components, no clutter and an emphasis on key-strokes and modifiers to execute commands. The problem, though, is the question of whether that suits everyone else, namely, your market. You are writing this for everyone, right?
Taken a look at Word lately? Have a look at the freaking insane number of menu bars and icons. Have you ever even used these? Probably not because you're a clever, blogging, power user. But do you think anyone uses them? It can't be denied there's a possibility they do. The logic then is that if someone might need to click on a disk icon, instead of pressing CTRL-S, then perhaps we should leave it there.
So while you can take this very brutish approach to designing your UI and say well, I'm not going to support this. It's plainly clear what you need to do in my application without this superfluous dogpile and I refuse to cater to the minority of users who want it. you're ignoring a potential fly in your ointment.
What about people with disabilities who rely on aiming for that one icon to save their document? What about those people who genuinely struggle to see their way through the maze of menus to find Page Setup or Styles? You know they're out there. Deep down you know it.
And so you sit down to design your UI and these things come to mind. I went up and down on this roller coaster this evening while working on a draft of a UI for an app' I am working on. The resolution was that I am going to document well, have a decent tutorial and keep my UI minimal. If ever this thing gets out there and I receive a pleasant email from a user telling me that they could really use a little help on the UI-front I've promised myself I'll look into it.
After all, #ifdef LITTLE_HELP should do it.
* User Interface, for the non-software folk.
posted by W at 12:27 am
0 Comments:
Post a Comment
<< Home