It's about Perception

Question

It's about Perception

Viewing 10 posts - 16 through 24 (of 24 total)

You must be logged in to reply to this topic. Login to reply

maharlika Grasshopper Points: 10 More actions · Answer 1

I have come across many requirements specification for applications involving a user interface interacting with a database but I have yet to find one which adequately describes usability requirements. Very often usability requirements are worded like "the user interface must be user-friendly". How do you test for a requirement as vague as this? With the absence of adequate usability requirements, of course, test plans do not include adequate usability testing. There are a lot of articles and books on the areas of Human Computer Interaction and Usability Engineering. I believe that I.T. professionals building computer applications that interact with users should endeavour to make themselves familiar with these areas. I know that some would say it's only a matter of common sense. But professionals have studied and researched on these areas and have developed techniques and published articles/books to help other I.T. professionals to perform more effctive user-centered design and usability testing. So, let's make use of them and, hopefully, applications we developed would always likely be perceived as we expected.

Nicole Bowman SSCommitted Points: 1555 More actions · Answer 2

As people remember bad things better than good things, I want to make sure that any bad things in my databases and apps are minor so the users perceptions are not too tainted! To achieve this I want the users involved as much as possible. Sometimes they can help me work out a new way of doing something that is no problem for me and saves them heaps of time. I sketch out what the screens will look like and explain what the various buttons etc do and they let me know what works for them. It can also help the users work out what they really need. Once we have sorted out what and how they need to do things, I design the database and build the application. At this stage I set up a test version and work with the users (or a subset they nominate) to correct any bugs and misunderstandings regarding functionality. This seems to work well and mostly avoid big bad things before going to production!

Cheers,

Nicole Bowman

Nothing is forever.

Jeff Moden SSC Guru Points: 1004356 More actions · Answer 3

We need to make sure that our systems work with the user, that help the user and make their jobs easier.

Heh... I've been preaching that on this forum for years especially in the areas of performance, scalability, readability, and maintanability. Even time I've done so, people try to install the handrails and have a go at me. One of my favorite responses is "It will only ever need to handle {some low number} of rows so we took a short cut to meet schedule". Another good one is "Our customers can get better performance if they buy {some super expensive hardware listed here}". Another favorite is "You don't know what our schedule is". My reply has become "If you don't follow those implicit requirements, then neither do you because your code will break when you least expect it."

People all over the globe have corrupted the meanings of "paired programming", "extreme programming", and "Agile programming" all for the sake of getting things done faster and to meet some silly schedule that includes no time for actually doing things right especially when it comes to user satisfaction (the ultimate drive of "perception"). It's good to see an article/editorial that suggests that quality of code and user perception might finally becoming more important.

When it comes to perception, you frequently have only one chance to make a good impression. If you are driven by schedule instead of user perception, prepare for a new career because, when it comes to perception, the customer is ALWAYS right. 😉 If you don't think so, as your competition that was awarded the new contract offered by one of YOUR customers. Why didn't you or your company get it? Heh... perception. 😛

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Steve Jones - SSC Editor SSC Guru Points: 736222 More actions · Answer 4

Jeff Moden (12/9/2009)
When it comes to perception, you frequently have only one chance to make a good impression.

You get one chance to make a first impression, but you can fix those impressions over time if you work at it. Not an excuse to fail the first time, but don't think all hope is lost.

Jeff Moden (12/9/2009)
If you are driven by schedule instead of user perception, prepare for a new career because, when it comes to perception, the customer is ALWAYS right. 😉

I like this quote. You ought to be driven by doing a good job for the users. Not necessarily any particular one, but the majority of the, rather than some schedule.

alen teplitsky SSC-Dedicated Points: 30014 More actions · Answer 5

good podcast

where i work most of the apps are internally developed. I even joke sometimes that it's like Quake point releases in that there are a lot of small updates for bug fixes and minor feature updates.

over the years we developed a system where each new version of the application is first tested in QA and then a sample of the user base. I think they call it User Acceptance Testing. Once everyone says it's OK it is then approved for release and the same sample users run another test right after the new release version.

bugs still slip through and we have had instances where we roll back to the previous release but things have improved a lot over the years. and the users also send a lot of feedback to developers via trouble tickets or email about features they want to see or problems in the current version

Gary Varga SSC Guru Points: 82166 More actions · Answer 6

Perception is key. Especially to performance.

Within a UI context, users are more likely to be patient when you use a wait cursor so that they know that work is being performed in the background (perception not threads). Or even better if they can carry on working when a back ground task is occurring.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!

Kick6Tiger SSCrazy Points: 2380 More actions · Answer 7

I've been in a development shop where we built some amazingly powerful apps that went above and beyond the functional requirements. But, the designers were doctors and statisticians where as the users were mostly hospital administrators. It's always important to gather the right input on design up front or you could end up with one powerful tool that's difficult to sell or never used. On the flip side, some of the quickest and dirtiest apps I've been a part of have been extremely popular/successfull only because the UX was slick on an iPad. 🙂

Aigle de Guerre!

Jeff Moden SSC Guru Points: 1004356 More actions · Answer 8

Gary Varga (10/17/2014)
Perception is key. Especially to performance.
Within a UI context, users are more likely to be patient when you use a wait cursor so that they know that work is being performed in the background (perception not threads). Or even better if they can carry on working when a back ground task is occurring.

Heh... I've found the users appreciate it more if the code runs fast enough where there's no time to even display a wait cursor. 😀

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Miles Neale SSChampion Points: 13147 More actions · Answer 9

I cannot believe I did not post on this topic when it first came out.

There is something to be said about this that I think is important. All applications will fail, and there are various reasons, including failure of service due to networking, infrastructure, the proxy run by someone else, or other factors no within the domain of the application or developer. Add that to the reasons the app itself may fail and you have a very high probability that there will be failures in most if not all apps over time.

The trick is that we need to provide the service in a usable way that meets the business need in as user friendly a manor as we can while maintaining data integrity and the correctness of process. If we can provide such a service the user will overlook and understand the points of failure, and will return to using the app once the problem is addressed. However, if we write an app that is hard to use, only gives people a small part of what they want, and runs only some of the time user loyalty will be nonexistent.

Happy Friday!

Not all gray hairs are Dinosaurs!

akljfhnlaflkj SSC Guru Points: 76202 More actions · Answer 10

I fully agree. Our IT delivers to in-house users. We get them involved prior to release so that we have a user that will make sure we have developed an app they will use and champion the product to others once released.