SE401:33:Cognitive Dimensions

Cognitive Dimensions Framework

Analysis of our application using the cognitive dimension framework

The dimensions can be used to evaluate the usability of an existing interface, or as heuristics to guide the design of a new one.

They provide a common vocabulary for discussing many factors in interface design.

Abstraction gradient

What are the minimum and maximum levels of abstraction exposed by the notation? Can details be encapsulated?

• Mashup elements are a low level abstraction

- they cannot be further broken up logically

• WYSIWYG editor allows for low level abstractions

Closeness of mapping

How closely does the notation correspond to the problem world?

• WYSIWYG editor view simulates exactly what the mashup will look like

- This is a high closeness of mapping

- Form editing uses common Internet terms and should be known by novice users

• Application looks like other Windows applications

- Provides familiarity for users

- Same icons as programs like MS Word

- Mashup element icons use official icons for quick recognition

Consistency

After part of the notation has been learned, how much of the rest can be successfully guessed?

• Mashup elements all follow the same input structure

- Once form input notation is learned, most can be guessed

- FormattingData is a little more complicated and may be harder to guess

Diffuseness

How many symbols or how much space does the notation require to produce a certain result or express a meaning?

• One symbol (placeholder image) is needed to represent each mashup element

- The sidebar provides another view (textural)

- Both views are kept consistent

Error-proneness

Does the notation induce mistakes in the user?

• The user can edit the source code if they wish

- Affects consistency

- May break mashup

• Certain combinations of mashup element and basic html functions (align etc) can create problems

- Problem with code base not our part of the tool (FUTURE WORK)

• Form creation/editing for mashup elements and form error checking eliminates most of the possible user errors

Hard mental operations

How much hard mental processing lies at the notational level, rather than at the semantic level?

Are there places where the user needs to resort to fingers or penciled annotation to keep track of what is happening?

• There are no hard mental operations

Hidden dependencies

Are dependencies between entities in the notation visible or hidden? Is every dependency indicated in both directions?

Does a change in one area of the notation lead to unexpected side-effects?

• Editing an RSS feed will only update the RSS feed object

- Any Google/Yahoo Maps or FormattedData using the RSS Feed will not update

• RSS Feeds are not shown in the WYSIWYG editor view

- User can accidentally delete the hidden tags for the RSS code (Not a big deal because code is only for show)

Premature commitment

Are there strong constraints on the order with which tasks must be accomplished?

Are there decisions that must be made before all the necessary information is available? Can those decisions be reversed or corrected later?

• RSS feeds must be loaded before creating an object which will use it

- Google/Yahoo maps can be made with no RSS and changed later

- FormattedData needs an existing RSS feed

Progressive evaluation

How easy is it to evaluate and obtain feedback on an incomplete solution?

• HTML preview allows the user to see a rough estimate of the incomplete page

- However to actually test the page the user will need to upload the document to their site

- Google Maps/Yahoo Maps/YouTube only provide placeholders not actual result

- RSS Feed data can be viewed in the source code for more advanced users

• No dynamic viewing of document is available in our application

- JavaScript is not supported

Role-expressiveness

How obvious is the role of each component of the notation in the solution as a whole?

• RSS Feeds purpose may be not obvious

- The user may not know why you would want this

- The user may not know what a feed is

- The user may not know how to make one or obtain one from an external source

Secondary notation

Can the notation carry extra information by means not related to syntax, such as layout, colour, or other cues?

• No secondary notation allowed

- HTML comments are not yet supported

- More advanced users can manually add comments in the source code view

- Layout/Colour are HTML syntax

Viscosity

Are there inherent barriers to change in the notation?

How much effort is required to make a change?

• Mashup elements are easy to edit

- Dialog boxes provided for editing

• HTML preview allows the user to add new content at any position and delete any content

Visibility

How readily can required parts of the notation be identified, accessed and made visible?

• Google/Yahoo Maps do not show location markers for rss addresses

- User must upload document and try manually to see result

- More advanced users can view the address data embeded in the JavaScript using the source code view

• YouTube videos cannot be previewed

• RSS feed data cannot be viewed

- Data is visible in source code view when combined with a Map - more advanced users only

• Formatting RSS data does not show the resulting data

- Results are temporarily printed to the console

• Sidebar allows the user to quickly view mashup elements in use in the current document

- User can quickly access the edit/delete options for any mashup element using this sidebar

◄ Back