|This article is of interest to the following WikiProjects:|
- 1 Proposal Version 0.1
- 2 Design for user-Friendliness
- 3 Usability Testing?
- 4 Definition
- 5 Wikipedia:WikiProject Usability
- 6 References
- 7 Merge Usability Requirements
- 8 Example moved from article
- 9 Rationale for distinctions list removal
- 10 This article is getting unnecessarily cluttered
- 11 Investigation
- 12 Cognitive modeling methods section
- 13 History of Usability
- 14 Page usability
Proposal Version 0.1
A Wikipedia article about usability should include - Proposal
- What is usability >>> Definition = usability
- Do we really need user? >>> Strategy = User innovation, and link to: Eric von Hippel
- What we wanna figure out? >>> Functionality requirements = Usability Requirements; Ease of use is actually the "super generic" requirement
- How to milk information? >>> Methods for user analysis =
- What to consider during design? >>> Usability Principles =
- Interaction design pattern, Usability pattern,
- Who are the Gurus of usability? >>> Usability experts and their principles =
- How to verify gathered information? >>> Methods for usability testing = Usability testing, Usability lab
What about adding some examples of "usable" products, e.g.the huge success of apple's ipod. Lawrence Lessing, the Stanford Law professor and wired columnist also has a book called the laws of simplicity. Is this relevant here? AleXd 22:37, 4 November 2007 (UTC) comment added by AleXd (talk • contribs) 22:34, 4 November 2007 (UTC)
fields of science
What fields of science are dealing with usability? (Everywhere a human interact with a machine - in abstract sense)
- Human Factor Engineering (in Wikipedia as "Ergonomics")
- Software Development
- Innovation Management / "Classical" New Product Development
- That is about the lead user thing by Mr. v.Hippel, what is also critizable
- It mainly deals with "How to get the user in my Product Development team"
- Issue: It focus mainly on tangible products (human-physical product-interface)
- However, Software is actually part of most "physical products", and sometimes software is a product on its own.
- Medical Devices for all of the above fields (HFE, SD, NPD)
Special Events / Public Relations
Design for user-Friendliness
Hello, yes i support to merge everthing into usability:
- Ease of use (Proposed to merge: NO; elaborates on the learning curve; short article)
- Usability Requirements (Proposed to merge: YES; deals with New product development requirements between supplier and lead firm; short article)
- User-centered design (Proposed to merge: YES; is a method; long article)
- User Centered Design (Proposed to merge: YES, merge with above; is the same method; lousy article)
- User experience design (Proposed to merge: NO, is a variant of the method above)
- Lead user (Proposed to merge: NO, merge with above; is the same method; short article; How Mr v.Hippel want to bring people together)
- User innovation (Proposed to merge: NO, merge with above; is the strategy behind the method above; short article; How Mr v.Hippel want to bring people together)
- Usability testing (Proposed to merge: NO; is a method; long article)
- Usability engineering (Yes, Mr Norman and Mr Nielsen are "Gurus". I acknowledge that. But maybe they transfer to subchapter "usability expert"s)
- User interface design (Actually, the Chapter "Processes" may be an good outline for all the topics above! Or, at least a starting point)
- Universal usability (Yes, Mr. Shneiderman is also an "usability expert")
- User experience (merged with User experience design)
- User Friendly (This page is just funny, but not really meaningful. It might be categorized as "public perception of usability")
These Wikipedia articles talk about the same, refer to the same set of methodologies, and deal mainly with the same - the user. Having so much Wikipedia articles about the same does not symbolize "good" usability (or whatever "us.."- word you like) —Preceding unsigned comment added by Hanwufu (talk • contribs)
- You have a good point, however I see a few problems. Most importantly, there are many more articles with extremely similar content. Also, some of the ones you list are definitely distinct topics. Finally, the effort to required to do a multi-article merge is considerable. I think at this time it would be best to tag near-identical articles for merger in pairs only, and go ahead and merge those that have already reached consensus for merger (I think there are a few if I remember correctly). --Ronz 01:10, 21 February 2007 (UTC)
- I've never made a list of all the related articles, but have many of them in my watchlist. Let me know when you're ready and I'll try to put a list together. --Ronz 17:35, 21 February 2007 (UTC)
Much of this page duplicates the content of the page on usability testing, which has been around for several years. Might some of that page be brought here instead? Also, this page was written with a software-only focus. Further, as a technical writer, I've worked with usability issues in web design (which is arguably at least nominally a software issue) but also printed material such as manuals and checklists (which are not). -- Dennis G. Jerz, 30 Aug 2003
Moved here from the article page, where it was not appropriate to be in inline with the text.
[This is too narrow a definition. Usability also has to address fields outside of these two, for example, linguistics and software engineering. The usability engineer has to recommend solutions; if he or she does not understand factors such as the technology or the constraints of the programming language, he or she cannot recommend appropriate solutions -- solutions that can be accomplished. ][The usability experts primary task isn't to recommend solutions but to identify usability flaws by the mentioned methods of usability testing. Finding appropriate and realizable solutions finally has to be a colaboration of the usability expert with the hardware or software engineers. Hardware and software engineers are the experts concerning the inherent constraints of the used technology, usability experts are experts concerning the constraints of human beings (human informational processing abilities for instance) who try to use the hardware or software.] It is important the the usability engineer not have a possible technical solution in mind, this may cause them to ignore issues and concerns which cannot be addressed by the potential solution. It is also important that the usability engineer not be too close organizationally with the developers, since then possible solutions may be discarded as "too much work" or "already considered and rejected".
When I studied computer science back in the 1970s, the term 'user friendly' was already an established concept, and there were most likely already textbook definitions. The general notion was that as computers were becoming relatively cheaper, and labor was becoming generally more expensive, it made sense, for the first time, to cater the computer interface more to the user, rather than requiring the user to cater his or her actions to the computer. For example, it was easy for a computer to convert a phone number from a variety of typed formats to a standard one for internal storage. So it was not 'user friendly' to expect the user to worry about whether or not to use hyphens or parentheses. Likewise, it was not user friendly to reject a date of '8/2/05' (a bad example for the 1970s) and insist on '08/02/2005' when it should be obvious to a programmer how to convert one to another, and when there is no ambiguity, such as when asking a user which bank statement is desired.
Thus, 'user friendly' was used to express that something catered to the user, rather than to the computer. Otherwise, the word 'friendly' would have been sufficient.
Having a discussion of 'user friendly' that says, well, we don't know what it means... does not contribute much. Surely, somebody must have reference material that discusses the historical use of the term and what goals were meant to be accomplished by it. -- wresnick 18:52, 23 May 2006 (UTC)
I've recently created a Usability WikiProject. The intent is to make Wikipedia easier and more pleasant to use by encouraging things like accessibility, Cross-browser support, standardized templates, and so on. If anyone's interested, please have a look at it, and see if perhaps you'd like to join. –MT 29 June 2005 03:08 (UTC)
When adding new references, please indicate what content is drawn from that reference if it isn't obvious from concurrent edits. Otherwise the addition could appear to violate WP:SPAM and/or WP:EL. --Ronz 19:06, 19 September 2006 (UTC)
Sorry, complete newbie here, but I noticed a problem with the first link under "Professional associations": "Usability Solutions." The link is not a professional association, but rather a link to the professional consultancy Human Factors International.
Merge Usability Requirements
I agree on the merge. The requirements article is only a few, unsourced, linkless sentences written by a single editor. --Ronz 19:14, 19 September 2006 (UTC)
I too concur on merging the 2 documents since Usability is still a niche area where many areas are yet to be explored. As the area matures, the articles can be split. However, till then, I think it is logical to keep them merged. -- Karthi.ShanmugamATyahoo.com
Agree with Merge. The article is unsourced, but the phrase "Usability Requirements" yields 147,000 hits on google so it deserves to be its own section. As stated above it can be split at a later date. -George100 07:37, 27 December 2006 (UTC)
I Disagree with the merge - Usability requirements are a type of requirement. Usability is a product attribute, and goes far beyond technology or system requirements. All existing products have an attribute of usability which is measurable. Usability requirements only exist for planned products or systems. The articles are related, but distinctly separate topics. --Lyle Kantrovich
- Yes they're different, it's just that there isn't enough in Usability Requirements to warrant a separate article, and I think this article could easily merge the content and gain more focus as a result. --Ronz 17:42, 18 January 2007 (UTC)
Agree with Merge. I don't see a good reason to have a separate article on the requirements only. They may be different for different applications, devices, or services. Such aspects of usability belong to the "usability" article. --Cameltrader 17:59, 22 January 2007 (UTC)
Example moved from article
I moved this from the article for discussion. It's unencyclopedic as is, but I'm also unsure of the need for such an example. Thoughts?
An example of a web interface built around a form that gets a personal address from a user may illustrate the difference between the two components. If the form uses a user's postal code to determine his or her address, it may be just as effective as one that did not, but much more efficient from the user's point of view. Why? Because time and effort is spent by the web server looking up a location rather than the user having to enter their address.
--Ronz 01:23, 25 January 2007 (UTC)
Rationale for distinctions list removal
The 5 usability distinction levels seemed to be simple self promotion than accepted principles. I do not think that this belongs in this article. Note that the wiki page for K Tara Smith has also been tagged for deletion. The main problem is that the list is not well described and confuses usability (level 1 and 2 - highly focused on context) with usage/usefulness and audience choice (levels 3 to 5 – focused on reapplication without focused context). Context should be emphasized here as any UI engineer or interaction designer knows that the first response to the question of usability will typically be "it depends". The current section does not seem to be very solid. A better place for these "distinctions" might be a separate wiki page where the author of that section can gather his thoughts and document his concept in detail with references. For example, I was not sure whether the "distinctions" build upon one another. If they do, just because something is not extensible does not mean that it does not have a high degree of usability. For the adoption level, there is an assumption that just because something is easier to use that it will be adopted and assumes that perception does not affect acceptance. 22.214.171.124 (talk) 21:57, 11 February 2008 (UTC)
This article is getting unnecessarily cluttered
People seem to have added a lot of low use, miscellaneous data to this topic. There is also an issue that the content of multiple articles have been jammed into a single article rather than creating individual, more targeted articles. The bigger you make it and the more clutter you add, the less usable the article becomes because users will have difficulty differentiating core concepts from miscellany. This is also in need of an editor to remove duplication. The sections that should be split-out include:
- ISO Usability Standards (at least 80% irrelevant to the understanding of the concept of "usability")
- Usability testing (should be added to the existing wiki article)
There is duplication in areas such as "system acceptability" which is the same as the "five quality components". Other sections are not well categorized and the entire article now looks disorganized.
- I've done some work. As here doesn't seem to be much feedback, I suggest you go ahead. --Canaima (talk) 23:49, 16 May 2008 (UTC)ó
Usability can be directly measured and I resent the rushed rhetoric. 5 criteria listed immediately above is a good place to start: observe/poll - initial usage, usage after familiarization, with clients that the solution is designed for and potential clients but uninitiated to the new design... just for starters - that contributor does not want to take the time to do it right. —Preceding unsigned comment added by 126.96.36.199 (talk) 10:57, 29 September 2009 (UTC)188.8.131.52 (talk) 10:51, 29 September 2009 (UTC)
The 'Investigation' section is clearly written and comprehensive. However, it contains no references, and reads like an instructional piece in some places. Some sources and light editing would improve it, if anyone can help with this (I'm not a usability expert, just interested in the topic).SkyeWaye (talk) 19:19, 19 April 2010 (UTC)
Cognitive modeling methods section
The cognitive modeling section contains a subsection called "Parallel Design". I don't believe this has anything to do with cognitive modeling. The way it's described in the article is that it's simply a collaborative design method that has each member of the team come up with competing designs, evaluating the designs as a team, taking each other's best ideas, and then iterating the process to evolve the final design. Nowhere is a cognitive model described or referenced.
Could someone explain how this relates to cognitive modeling or otherwise remove it from the page (I don't believe it has anything to do with usability and simply sounds like a general collaboration technique that could be used by any kind of creative team).--184.108.40.206 (talk) 00:49, 10 November 2010 (UTC)
History of Usability
The article contains nearly nothing about the history of the concept or its repeated discovery, rediscovery and reintroduction. As one who "was there" before Apple introduced the (eminently usable) Mac in 1983, I expected to see some indication of the work from around 1950 or 1960, and perhaps even contain a reference to Bush's Memex. Nearly all the cited material is 1990 or later. Who did the early work? Snezzy (talk) 10:56, 12 February 2013 (UTC)
- Lack of content in one area usually comes from a lack of knowledge about it. If you're someone who was there, can you point us to some general references describing that early period? Diego (talk) 13:00, 12 February 2013 (UTC)
Please don't take offense, but its kind of ironic that a page about usability is so difficult to use. There is a ton of material on this page, but it is really intimidating to try to find anything. The page seems to be explaining every single aspect about studies on human factors engineering instead of discussing usability with supporting references. I understand this is a very complex topic, but are so many different sections really required? It seems that some sections should be segmented out into separate pages. Many of the headings can be referenced in a paragraph with a link to another page with the explanation of what it is. I mean is a conclusion section really necessary? Does every one of Nielsen's Heuristics have to be described or can there be a reference to a separate page on this? It would probably be best to consider the importance of minimalist design and its impact on the designs effectiveness when revising this page. There is a lot of very good material here, but the page makes it seem overwhelming. — Preceding unsigned comment added by 220.127.116.11 (talk) 09:08, 7 August 2013 (UTC)