GemX's Classy Reply to Daly's Questions
< Next Topic | Back to topic list | Previous Topic >
Posted by quant
Jun 28, 2008 at 07:10 PM
>I’d go farther than that. I think that well-designed, usable
>software should not need a help file. If someone needs to look at the help file then they
>are experiencing a flaw in your design. (I know this is an impossibly high standard -
>but it’s an ideal that developers should shoot for.)
simply impossible
Maybe, we, users, could just admit that we don’t know everything, and have a look at the help file what developer meant by something, and then if some doubt remain, ask in forum or contact developer.
I am sure that most of the answers to user questions that developers get from users can be found in the help files, but users are lazy ... it’s much easier to ask in forum or email developer and get the answer instead of wading though the help file.
The moral of this thread is, RTFM!!!
Posted by dan7000
Jun 28, 2008 at 08:35 PM
Hey Pierre,
I’m not intending to criticize your software - I’m just voicing a philosophy I’ve had in my own software development efforts. Disclaimer: I was engineering manager for Quicken for 5 years. I also designed and developed some other fairly popular commercial software. I never met my own standard for intuitive usability but I always pushed my team to think of it this way: if you need to point to the help file, it’s a usability flaw.
Sure, it’s easier to achieve this goal with established software paradigms than with new or innovative ideas. But new ideas can also be intuitive for users. TiVo is of course the best example. The oldest, least-tech-savvy visitor to my house can operate our TiVo immediately, even if they’ve never seen a DVR before. Another brilliant example is the world wide web. I remember in 1994 or so - if you used Prodigy you were always looking at the help file. If you used compuserve you were always trying to get help in the forums. But anybody who lauched a web browser instantly knew what to do - there was no instruction needed, for the newest, most innovative technology idea in the history of computing.
The key to intuitive usability for new software paradigms is to adopt a metaphor to an established paradigm. For instance, when Quicken was a brand-new idea, it adopted the checkbook metaphor. The entire program looked and operated like a checkbook, and that was the key to its success. At the same time, other programs tried to force a database or spreadsheet approach to personal finance management, and they all failed miserably. Today, other software can provide the metaphor: if something has columns, we expect it to sort when we click on the column header; if something has an “OK” button, we expect our data to be saved; if it looks like excel, we expect to be able to edit cells in-place. Software designers can look at every aspect of our programs and ask: what is the metaphor for this? How can I make it intuitive and obvious?
Posted by Sarah
Aug 7, 2008 at 07:07 AM
Hi Daly,
I know this is kind of an old thread, but the response you received from Jon at GemX still sits in the back of my mind.
I’m quietly hoping (OK, praying) it’s still being worked on. This software helped me stay focused like nothing else.
To me, it was a priceless productivity tool with a concept / layout that was unmatched by any other application.
So…did you end up buying Do-Organizer?
Or, at least, get a chance to test it further?
Just curious!
:)
Posted by Christophe
Aug 7, 2008 at 08:36 AM
Sarah wrote:
>Hi Daly,
>I know this is kind of an old thread, but the response you received from Jon at
>GemX still sits in the back of my mind.
>I’m quietly hoping (OK, praying) it’s still
>being worked on. This software helped me stay focused like nothing else.
>To me, it was
>a priceless productivity tool with a concept / layout that was unmatched by any other
>application.
>
>So…did you end up buying Do-Organizer?
>Or, at least, get a chance
>to test it further?
>
>Just curious!
>
>:)
>
>
I totally agree with Sarah’s comments about Do.Organizer. She’s so right ! ;)
Posted by Dale L.
Nov 12, 2008 at 01:15 AM
Personally, I have to disagree with the above claims in this thread. And that was: “if you need to go to the help file… then there is a flaw…”. I think that in the case of do-Organizer, this is not true - and perhaps in many other applications as well. The quick assumption is erroneous to me. Just by experience on forums and emails, most people ask for things that are so obvious and the reason is they “prefer” to talk it over with someone and let that someone “walk them through” instead of doing it on their own. And by far, that’s in the majority of cases. The core concept of doO is so simple and very intuitive and that’s fine. But when you have many features and the application is well developed, eventually, you would need help files - and that is perfectly normal. There simply is NO application out there that matches doO’s intuitiveness and capacity - none! In many cases, on the developr’s side, so much time is taken up for developments and regular office duties, they simply do not have the time to “walk people through”. And they don’t have the time to answer obvious questions that are so easy to find answers for… and users “should” do their homework before requesting support - but many don’t do that and they quickly jump at the developers who basically have no time for such things - and yes, that’s perfectly normal as well. I also think that generally, people have become too hard on developers and are so ultra-demanding - it just doesn’t make any sense - business wise. Some people are simply never satisfied. Support demands in many cases are so unrealistic. I think we have gone on an extreme on this issue. I have learned to cool down with that. I was just like everybody else - so demanding and so intolerant - but - I eventually understood, I was doing more harm to myself than anyone else. And I missed out on great opportunities because of my “hard” attitude. Well, I learned to be a little bit more “supple” and “flexible” - more understanding instead of demanding… and more supportive towards developers - afterall, it’s a two-way street - (or at least it should be) - they need support too. I find myself more in a position to enjoy developer’s products today. I`m not trying to preach to others - don`t get me wrong - but that`s just what I think about the situation with software developers. I think we’ve gone overboard with this “client support” thing - in general. And with that, I`m not trying to cover for support failures either but I’m basically aiming at a well defined balance from BOTH ends of the story - that`s my personal target. To make a simple illustration about GemX, and doO, well, they’ve helped me so much in getting organized like no other has and in return, well, I think they deserve some support from me. Why should I say: they didn`t answer my email and so that`s it! - I have had enough and that`s it! I delete the app never to come back - c’mon, people, is that the way to go? You just look at the flaw and all the good accomplished is wiped out of your memory banks. Good grief, where is your balance, kindness, and understanding?
A simple learning curve is “normal”. What’s up with people who do not appreciate a little challenge in learning anything in using softwares…? It doesn’t make sense to me. I like a software that brings a challenge in learning. I think that there is a balance in all things. The idea that: “when you need a help file signals a flaw” is a perfect example of an “extreme” and not a balance. Help files are essential and must be there for the benefit of users. And yes, in general, users are lazy and would rather someone “do it” for them.
It’s good when developers can be “honest” and tell it like it is - that helps. But we all know it’s a struggle out there to survive as an online business in the software industry. So why demand perfection…?!!! Is that realistic or sensible? If people would stop using the “net” as a battleground and a cut-throat arena, and instead, use it as an opportunity to help one another then the internet world experience would become better for all…