Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Usingheuristics

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Human-Computer-Interaction - Team (category HCI)


Why heuristics

Having initiated and since followed the work taking place in the HCI group for some time, we thought it would be a good time to elaborate a little on the posting of the Bødker and Nielsen TYPO3 heuristics, posted about a week ago on this list (see Heuristics).

The reason for the post was to try to create a common departure for discussions of issues related to the usability of the TYPO3 backend. We have seen how the list often discusses very specific design or labeling aspects of the TYPO3 interface. Yet while these discussions can be of value to a few fellow developers who perhaps struggle with similar problems, they are not necessarily of any great value to the TYPO3 HCI community. Therefore, the heuristics were posted as an attempt to create a common ground around the valuable knowledge that is being generated here on the list. Rather than talk about specific problems, a list of heuristics should enable a frame from where all developers (i.e. those interested in HCI aspects) can talk.

This is not to say that everything, every problem or question, should necessarily be framed within the confines of the heuristics. There should still be space for the specific, the ad hoc and the "here and now" help that the list is so good at. Also, it is important that the Bødker and Nielsen TYPO3 usability heuristics is not seen as a static list, but as a working and dynamic document. Therefore we encourage questions, additions and elaborations to the 10 points that we have initially proposed. Especially, we like it if you have examples of where you'd think some of the heuristics apply, and how they might develop into an efficient reference tool for all of us.

An elaboration of the heuristics based on Jens Hoffmann's PDF.

Going through some of the problems he elaborates, we will try to connect these to the heuristics. We find that if we, on the list, could develop a central point of reference from where all (or at least most) HCI issues could be addressed, we'd be closer to being a true, knowledge sharing HCI community able to develop and grow, become better and more efficient in dealing with problems as a group, as more problems are encountered.


Typo3 usability - using heuristics

IMPORTANT: Would be great to see the charts. Where are they? Does someone know?

Chart no. 4.

Relevant to users needs While it is reasonable to make distinctions between different kinds of users and use, the question is if this chart incorporates the distinction between different kinds of actual users. Rather it seems to make distinction between use situations and work tasks. In our research we have encountered three different kinds of users. The highly competent user, often on admin or developer level, the competent editor who uses the system on a daily basis, and the insecure user who uses the system on a monthly basis. These are actual users and they require different forms of interaction with the system, even though they have the same work tasks. In this case, relevant to users needs are to consider different kinds of users needs, not different work tasks.

Chart no. 7.+ 8.

Consistency and standards - recognition rather than recall As it is rightfully pointed out, the interface should not be a mixture of different conventions and aesthetics, and there should be no more than one way to interact with the different functionalities. This is the case because it is good follow acknowledged standards, but also because the user should not have to remember how to do things, but be able to figure it our intuitively.

Chart no. 13

Law of proximity The Gestalt law of proximity states that "objects or shapes that are close to one another appear to form groups". For many reasons, it is agreed that it is good to have just one basic content holder for the system. But, drawing on this heuristic, even for this one holder, it is important to design it in a way that helps users understand the relationships between functionalities and the actual result. The law of proximity point to that we understand things that are close together as a group and we expect things that are close to each other to be related.

Chart no. 14

Consistency and standards As rightly pointed out a functionality like windows helps the user to know what to do.

Chart no. 19

Match between system and the real world The new suggestion for menu structure reflects the work done by different kinds of users and there is a match between the system and the real world of the user. The menu "Extensions" falls outside this. A user might not understand what an extension is and in the daily tasks creating a newsletter or a direct mail is just part of the job and not so different from creating a page.

Chart no. 25+26

Law of proximity The menu structure does not reflect that elements close are considered a group. E.g. Tool 1, Tool 2 and Help seem to belong to the same group.

Chart no. 29+30

Use of metaphors Looking at the metaphors they do not seem to enable users to instantly grasp the finest details of the conceptual model. It is not intuitively to understand what the icons are metaphors for.

Chart no. 32

Fitts's law The bigger a field, the easier to use, reflects Fitts's law: the time to acquire a target is a function of the distance to and size of the target.