Problem
Statement
One
trend in website development is to disseminate the responsibility
of managing content for a website to the people who generate
the content rather then having the webmaster handle every small
addition or change. When the responsibility is disseminated,
the webmaster can focus on larger website development issues.
The possible drawbacks of disseminating the responsibility
of content creation are the following: people who may be uncomfortable
with HTML and other aspects of web design are forced to complete
tasks for a website, someone in the organization needs to ensure
that all of the additions and changes to the website meet the
organization's standards, and the webmaster needs a tool that
allows him/her to manage all the files generated for the website. The result of managing web development in this
manner is that there is a group of people working on web development
with a wide range of skills and needs.
More specifically, the novice user needs a system that
allows them to seamlessly make additions and changes to the
website. The webmaster
needs a system that allows them to manage all the style sheet
files, graphic files, and document files that comprise an organization's
website. Finally, the
Vice President or executive with overriding control needs a
system that allows them to review all additions and changes
to the website.
Another
trend in website development is that organizations are supporting
different types of websites that all have the same content. For example, in addition to maintaining a basic
HTML site, an organization may have a wireless website that
uses the wireless application protocol (WAP).
The organization may also have a site that uses Flash. Thus, there is a need for a system that will
ensure that the content on all of these sites is the same.
Solution
Overview
In
order to address the problems that result from disseminating
the responsibility of web content, we propose a Content Management
System (CMS). This system
allows users seamlessly work with documents, style sheets, and
graphics in order to make necessary changes and additions to
an organization's website.
The system is designed such that different users have
access to different features within the system. For example, a novice user may only have rights
to work with documents in the system.
The novice user is probably uncomfortable with web design. CMS allows the novice user to work with a document
for an organization's website without using an HTML or other
technical aspects of web design.
At the same time, an experienced user like the webmaster,
could have access to every feature in the system.
The webmaster user could use the system as a tool to
manage all the graphic files, style sheet files, and document
files that make up an organization's website. CMS also provides a section called the Verification
Console which allows users with certain rights to review document
changes and additions before they go live on the organization's
website. The Verification Console meets the needs of
the Vice President or executive who has overriding control over
the documents for the entire website. Finally, in order to address
the problem of multiple websites that need the same content,
CMS has a single content repository that is used to generate
the information presented on the various websites maintained
by an organization.
Personas
Persona
Development
The
Content Management System (CMS) is intended for anyone working
on web design in an environment where web files are stored in
a database. Thus, a CMS user can range from an individual working
on their own site to a team of people in a large corporation.
The team of users may include any of the following: content
providers, editors, graphic designers, backend programmers,
HTML coders, and many others. The primary goal of a CMS user
is to update or change an existing web page or to create a new
web page. The CMS system will provide an interface that allows
this goal to be completed seamlessly.
We
developed three different personas: Heather Renwick, Dave Salmonson,
and Mekki Okaraka.
The
personas and goals were mostly developed through the guidance
of real life experiences Chris has had in his work on web development.
Heather is based on a situation Chris has seen occur in the
real world several times. The situation we are referring to
occurs when an individual or an organization has a web site
developed and then is left with the task of making updates,
changes,
additions,
etc. The individual or organization lacks the skills required
to achieve their goals. Heather is also somewhat based on Chan
Jean's interview with Eddie. Eddie discussed this same situation
mentioned above in his interview. Mekki and Dave are loosely
based on Chris's former work relationships.
We
did conduct four interviews with potential users to access user
needs and goals for a content management system. As mentioned
above one interview was with Eddie. The other three interviews
were with 3 members of the SIMS web design team (Mary, Steve,
and Shirley). Unfortunately, our interviews only helped a little
in developing our personas. This is because of the nature of
our system. It is difficult to create questions that elicit
responses about a type of system that the users had not used
before. We feel that user input will be more useful when we
can give the users something to play with and get their feedback.
Personas
and Goals
Persona
1: Heather Renwick 
·
32yrs old, unmarried, Canadian, living in US since high
school
·
went to an all women's college and graduated with an art degree
·
loves training horses
·
is the head of marketing for Lobotech a mid-sized company in
the Bay area
·
has some computer experience in applications like word, Photoshop,
etc
·
interested in web development but doesn't have the time to learn,
spends all her time working
or with horses
·
not interested in any programming or anything else really technical
Goals
·
She wants to put certain kinds of information on the company web
site or changing information on the site
· wants to save time and money for Lobotech by doing web tasks
herself
·
wants to avoid feeling annoyed and frustrated when she asks someone
to do something on the web site and she has to wait
and rely on them to do something she is responsible for
Justification
Heather
exemplifies a real world situation where you have a person in
a position of power who is responsible for a technical activity
that they do not know how to do. This type of person cannot
do these technical activities on their own nor do they have
the time to learn how
to do them. Therefore, these people have to rely on others and
become frustrated.
Persona
2: Dave Solmonson 
·
VP marketing for LoboTech in his early 40's
·
American
·
Married, no kids
·
Did some work with web delevopment, but focused mostly on marketing
·
Has to okay any major changes to the web site or additions
·
He examines the press releases
·
Has editor characteristics in that he often makes minor changes
to content on the web site
Goals
·
to have a professional web site
·
wants to ensure consistency across all web sites maintained
by Lobotech
·
efficient mechanism to review modifications to web content before
they go live
·
effectively market Lobotech’s product
Justification
Dave
is a real world example of a person in a company who is responsible
for verifying that content is acceptable before it goes live
on the Internet. Dave has an editor function.
Persona
3: Mekka Okaraka 
·
23yrs old, unmarried
·
nigerian
·
speaks fluent English
·
attended high school in US
·
has traveled the world with his family
·
has just received his degree in CS from Pomona College
·
Senior web developer for Lobotech ( was working at lobotech
before he graduated)
·
fluent in flash, javascript, cold fusion, ASP, Java, SQL, etc.
·
very talented graphic artist, does 3-D modeling and animation
with 3-D studio MAX and MAYA
·
leads the bachelor life style---eats out every night, sports
car, fish tank, etc.
Goals
·
maintain the Lobotech’s web sites (Flash site, HTML site, Partner
Site, WAP site)
·
make modifications to text and graphics
·
distribute tasks to employees when appropriate
·
to reduce the amount of redundant work he has to do in updating
web material on various sites
·
to decrease the requests for help from other employees at Lobotech
who have to work with material
on the web sites
Justification
Mekka
represents an example of a person who is responsible for creating
and maintaining web sites for a business. He represents a user
group that wants easy things like maintenance to take as little
time as possible so they can spend time on bigger issues. He
also represents the user group that wants reduce other employees
dependency on him for every minor modification that has to occur
on the business’ web sites.
Persona
Revisions
We
have decided that Heather and Dave are somewhat redundant. They
are both in the position of working on a web site although they
have little or no web experience. They each have different purposes.
Dave needs to edit and approve content while Heather needs to
complete organizational related tasks. However, there overall
functions are the same. They both need to make changes, updates,
etc to existing web pages. Thus, we have decided to focus on
Heather as our primary persona. We have decided that if our
design meets the needs of Heather it will meet the needs of
Mekka. There is the possibility that Mekka will want more features
then Heather, but since he is an expert user, he can design
modules himself and attach them to CMS.
Scenarios
Scenario
1:
You
are working for Lobotech and need to add a company announcement
for the annual picnic to the company web site. You are going
to use the Content Management System (CMS) to complete this
task. As part of your job you know that the content for company
announcements is stored under the category AboutUS in the CMS.
You also know you want to let the default style sheet and graphic
apply for all three sites.
Scenario
2:
One
of your hobbies is drawing. You created a cool graphic of one
of your drawings in your spare time. You asked your boss at
Lobotech if he wanted to use it as the company logo. You boss
thought it was great and asked you to add the graphic to CMS
for the HTML site so it will be available when the webmaster
decides to use it. The graphic is currently on the desktop
of your computer under the name logo.gif
Scenario
3:
You
are the webmaster for Lobotech. You decided you want to change
the color for active links to white (#ffffff) in the default
style sheet for the HTML site. You know the name of the style
sheet file is newwap.
Scenario
4:
You
are the head of Human Resources for Lobotech. You asked an underling
to put a company announcement for the annual picnic on the company
web site. You now want to check that addition to the company
web site before it goes live.
Final
Interface Design
Functionality
Overview
The
Content Management System has a web-based interface that interacts
with an Access Database through Cold Fusion. The interface consists of the following seven
main areas, which are described in detail below: main page,
search, style sheets, graphics, documents, verification console,
and help. One important feature of CMS is that users
only see the areas of the system that correspond to their access
rights. The use of access rights allows users to only
see the parts of the interface that are necessary for them to
complete their job. Therefore,
users are not overwhelmed with the unnecessary details of web
design.
Main
Page
The
main page is the first page a user sees after logging into the
system. On this page
the user sees the options of working with a document, style
sheet, graphic, and the verification console depending on their
access rights in the system. In addition, the user is presented with the
menu bar across the top, which includes the following options:
documents, style sheets, graphics, verification console, search,
and help. One again, the user only sees the options on
the menu bar that correspond to their rights within the system. The menu bar is provided in every page within
the system so the user can go to any area at any time. Finally, it should be noted that at every page
in the system, the user has the option of canceling out of the
current process and logging out of the system.
Search
In
the search section, users are able to search for files using
the following types of metadata: title, category, last update,
last author, and type of file (document, style sheet, graphic). All of the metadata options, other then title
option, have drop down boxes to assist in the selection of the
criteria. After the
user searches, they are provided with a result list that matches
their criteria and matches their access rights within the system.
For example, if Heather searches for files that were
last updated on 4/24/01, she will only see document and graphic
files that correspond to the date criteria because she only
has rights to those two areas within the system. She will not see the style sheet files from
4/24/01 because she does not have rights to style sheets.
In
the result list, the metadata for each result file is displayed.
In addition, the user is provided with buttons for different
actions they can perform with the file.
For example, when a document is presented in the result
list, the metadata about the document is followed by buttons
that allow the following actions: modify the document, preview
the document, or delete the document.
Clicking on these buttons will take the user to the appropriate
place in the interface to modify the document, delete the document,
or to see a preview.
Help
The
help section provides users with a flow chart overview of the
entire system so that users can see how files flow within the
system. In addition,
the help section provides general information about all the
areas of the interface and how to complete tasks in those areas.
The help page is organized in a hierarchical format.
The first page has hyperlinks to more detailed sections
so that the user isn't bombarded with a large quantity of information
on the first page of the help section.
Verification
Console
When
the user first comes to the Verification Console, they are presented
with a list of documents waiting to be verified. Clicking on any of these documents will return
a page with a text box where the editor can view the text for
the document as well as table where the editor can view the
associated style sheet and graphic files.
The table shows which style sheet and graphic files are
used with the document for each of the different websites (WAP
site, HTML site, and Flash site). The textual content for each
of the three website is the same but the style sheet and graphics
for each of the three websites is not the same.
The editor is able to change both the text and the style
sheet and graphics that are associated with the document file. From this page, the editor has the following five options available:
preview the document, make the document go live as is, make
changes and make the document go live, save the document for
later, and e-mail the author about the document.
Another
feature of CMS is that when a user submits a document for verification,
an e-mail is automatically sent to the verifier (boss), that
a particular document is waiting for them in the Verification
Console. In addition,
the confirmation page for the user who submitted the document,
informs the user that the e-mail has been sent to the verifier.
Style
Sheets
After
selecting the option to work with a style sheet, the user has
to choose one of three options: modify an existing style sheet,
add a new style sheet, or delete a style sheet.
If the user wants to modify a style sheet, they first
select the desired style sheet from a list in a text box.
Then the user is presented with a page where they can
edit the style sheet and preview documents linked to the style
sheet. When the user is finished, they can either
apply the style sheet changes to the linked documents or save
the style sheet under a different name.
To
add a new style sheet, the user enters the title of the new
style sheet and clicks the add new style sheet button from the
three options mentioned above.
The user is presented with a page where they can enter
the code for the style sheet. The user also uses a radio button to designate
whether the new style sheet is designed for the HTML site or
the WAP site. When the user finishes they can add the style
sheet to the system.
To
delete a style sheet, the user clicks the delete style sheet
button from the list of three options mentioned above. Then the user selects the style sheet they
want to delete from a list of style sheets contained within
the system. The user can preview the selected style sheet
with a list of linked documents before deletion. Finally, the user can click the delete button
and the selected style sheet is deleted from the system.
Documents
After
selecting the option to work with document, the user chooses
the desired document category from a list of categories. The categories presented to the user depend
on the user's rights in the system.
After selecting a category, the user is presented with
three options: add a document, modify a document, and delete
a document. If the user chooses to add a document, they
have to enter a title. Then
they are presented with a text box where they can enter the
text for the document. In addition, the user has the option of selecting
the style sheet and graphic files for the document. The default style sheet and graphics files
are automatically selected for each of the different websites
(WAP, HTML, and Flash), but the user can change the default
selection. Finally, the user is given the following options:
submit the document to the verification console, save for later,
preview, and a go live button (if the user has verifier's rights).
To
delete a document, the user selects the delete button from the
list of three options mentioned above. Then the user selects the document they want to delete. The list
of documents provided to the user contains all the documents
included in the category the user chose prior to proceeding
to the current page. Finally, the user can press the delete button
and the document is deleted from the system.
To
modify a document, the user selects the desired document from
a list of documents. Once
again, the list of documents provided to the user contains all
the documents included in the category the user chose prior
to proceeding to the current page. Any documents in the list that are in use by
other people have the word LOCKED next to the document followed
by the name of the person working with the document.
If the user tries to select the document, an error message
will appear telling the user the document is in use by a particular
person. The error message provides a link that allows
the user to e-mail the person working with the document. The locks prevent accidental overwrites from
occurring. After the
user selects a non-locked document to modify and clicks the
modify document button, they are presented with the text box
which contains the text from the existing document. The user can make changes to the text as well
as the associated style sheet and graphic files for each of
the three websites. Finally,
the user is given the following options: submit the document
to the verification console, save for later, preview, and a
go live button (if the user has editor's rights).
Graphics
After
selecting the option to work with a graphic, the user has three
options to choose from: add a graphic, delete a graphic, or
view documents linked to a graphic.
If the user decides to add a graphic, they are presented
with a page where they can upload graphics for Flash or HTML
sites.
To
delete a graphic the user selects the delete button from the
three options mentioned above.
The user is presented with a list of graphics in the
system. They can select a graphic and see a list of
documents that are linked to the graphic.
The user can preview these documents with the graphic. Finally, the user can select a graphic and
delete the graphic from the system.
To
view the documents linked to a graphic the user selects the
view linked documents option from the three options mentioned
above. The user can select a graphic and see a list
of documents that are linked to the graphic.
The user can also preview each document with the graphic.
Interaction
Flow
Screenshots
Login
and Main Page
Style
Sheets
Style
Sheets: Add, Modify, Delete
Search
and Search Results
Graphics
Graphics:
Add, Modify
Help
Documents
Documents:
Add, Modify, Delete
Document
Locked
Verification
Console
Verification
Console for a Selected Document
What
Is Not Implemented
Our
interface has many features that are not implemented.
The Content Management System underwent major design
changes between the second prototype and the third (final) prototype.
Due to limitations on time, we were not able to implement
many of the changes. In addition, many of the features that were
implemented in the second prototype are no longer implemented. The code for the system is completely interwoven
and making one small change often results in other features
losing their functionality. Therefore, many of the features
on the interface are hard coded rather then actually implemented.
However, the features are still capable of demonstrating
how we would like the system to function.
Error
Messages
We
did not implement proper error messages. However, we did create an example error message
that demonstrates the way in which we would like our error messages
to function. This sample
error message occurs when a user tries to modify a locked document. The title of the document is Press15 and it is located in the Press
category.
Locks
We
did not implement the locks used in our system. The locks displayed in our system are hard
coded to display how we plan to use locks to prevent accidental
overwrites from occurring.
Currently, sample locks are displayed when the user is
looking at a list of document for modification. However, if implemented, the locks would also
appear in any part of the system where files are listed for
selection and are in use by someone.
Search
The
search feature is not actually implemented. The search function in our system is hard coded
and is designed to give an impression of the way we would like
search to function.
Documents
When
you choose to modify a document, the system should bring the
document into a text box called the DEM where the user can alter
the document. However,
after removing Ezedit to simplify our system, the system no
longer brings the document into the DEM for modification.
Clicking the modify button takes the user to the DEM,
but the text is not in the DEM for modification.
In addition, the system does not save the modifications
the user enters for the existing document. After the user modifies
the document, they can submit it for verification. However, the system does not actually send
the document to the verification console.
Another
feature that no longer functions due to the removal of Ezedit
is document addition. Users can click through the process of
adding a document and submitting the document for verification,
but the document is not actually added to the system or sent
to the verification console.
Help
The
help section is only partially completed. We have included enough information to demonstrate
the way we would like our help section to function.
Preview
Preview
buttons are available in the documents section, graphics section,
verification console section, and style sheet section of the
interface. However,
these buttons are not actually implemented.
Save
As/Save for later
In
both the documents section and verification console section
there is a save for later button.
In the documents section, this button allows the user
to save the document without being force to submit it to the
editor. In the verification console section, this button
allows the verifier to save the document without being forced
to make the document go live. Also, in the style sheet there
is a save as button that allows a modified style sheet to be
saved with a different name. Neither the save as or save for later buttons
are actually implemented.
Linked
Documents
In
both the style sheet section and graphic section, the user is
provided with a list of documents that are linked to the style
sheet or graphic. The
user can select a linked document and preview it with the style
sheet or graphic applied. However, the linked documents section is not
actually implemented.
Delete
Option
In
both the style sheet section and graphic section have a delete
option, which allows the user to delete a style sheet or graphic,
respectively. However, neither of these deletion buttons
actually function.
Go
live
In
the documents section, users with verifier's rights see an extra
button called 'go live' which allows them to make a document
go live without going to the verification console.
However, this button is not actually implemented.
E-mail
The
system sends an e-mail to the verifier whenever a document is
submitted to the system. However,
this part of our system is not actually implemented.
Tools
used to develop the system
Tools
for prototyping and implementing the UI and how the helped or
didn't help
The
two primary applications that were used to build the interface
were Cold Fusion Studio 4.5 and Macromedia's Dreamweaver Ultradev
4. Cold Fusion was used
interact with the backend Access Database and Dreamweaver was
used to create the front-end pages. Both of these tools are
incredibly powerful and useful.
One
of the nice features of the Dreamweaver 4 family is the ability
to visually create layers that are automatically resolved into
common HTML tables. Dreamweaver has always offered the ability
to create layers, the most effective ones in previous versions
usually had to resolve to DHTML layers, which were inevitably
incompatible with most browsers. This fact severely limited
the use of this feature. However, the new and improved Ultradev
4 makes it simple to visually try out new UI configurations
without coding a single line of HTML. It can also act as a quick
and dirty way to create wireframe pages before committing to
the final UI with graphic design embellishments.
Design
Evolution
Design
Sketches
We
developed two different design sketches for our Content Management
System based on interviews with potential users and based on
a task analysis. The
interviews and task analysis showed that there are three main
types of users. The first type of user is a novice user who
only wants to work with documents and graphics. The second type of user is a webmaster who wants complete control
over the entire website. The
third type of user is an executive who wants overriding control
over the content on the website. The sketches we developed incorporated
the needs of all three user types.
We then created a low fi prototype that was a hybrid
between the two designs because we liked qualities from both
designs.
Link
to Preliminary Design 1
Link
to Preliminary Design 2
Low
fi
As
mentioned above we created a low fi prototype of our design.
When then tested our prototype with users.
The findings from the low fi helped us to refine our
design for our first interactive prototype. However, the findings are relatively limited
because it was difficult to create a real environment for our
test. We conducted our test with people who worked
as part of a web development team.
However, CMS is a work specific tool.
In completing our tasks, the files in our system were
not 'real' files that were relevant to the user.
Without having content that was relevant to each user,
it was difficult for the user to imagine this tool in their
work environment and therefore it was difficult to discover
the problems with the interface. The users followed the tasks we gave them and
this process did elicit some problems.
Link
to Lo-Fi Prototype Pictures
Major
Problems identified by the low fi usability test
Terminology
Problems
·
It was unclear to the users that they should use the background
subsection to work with a graphics file.
·
The users found the term Editor's Console to be confusing. The
reason for this confusion is that there are 'edit'-like feature
in other parts of the site outside of the Editor's
Console.
Error
Prevention Problems
·
The users felt the update button in the verification console
in place of the submit button (found on all other pages) created
an easy situation for an error to occur. This button is in the
same position as the submit button on other pages in the system.
Therefore, it would be easy to hit the update button out of
habit before the changes are actually ready to go live. In addition,
they felt the button needed a more descriptive name.
Work
Flow Problems
·
Users noted that they would want to know how many documents
were waiting to be verified.
·
Users also noted that the interface for working with a style
sheet and document should be consistent.
·
Users did not understand why they had to select a category and
choose whether they wanted to add, delete, or modify a document
on the same page. They were unsure why they had to do both
actions to proceed.
·
Users were confused about the adding graphics section because
they only saw one type of graphic addition option.
Navigation
Problems
·
Users were confused by the quantity
of options available on the main page.
· Users
were also unsure where to go after they finished a task. The browser navigation and menu bar at the top were their
only forms of navigation. They
were looking for some navigation after the confirmation message.
Mode
Problems
·
The
Editors console represents a mode where users to do the same
actions that Editors can perform with the exception that non-Editors
cannot make changes go live. Users need more clues when they are in the
verification console and can make things go live.
Changes
for the first interactive based on low fi results
Terminology
Changes
·
Changed
the term background to graphics
Error
Prevention Changes
·
Changed
the button in the Editor's Console to say go live and put the
button off to the right so it is in a different location. Made
a stronger signal to the user that accepting a document in the
verification console makes the document go live
Mode
Changes
·
Provided
better indication that the user is was the verification console
using color and titles
·
Set
the Editor's Console apart from the other options on the main
page
Work
Flow Changes
·
Provided an indication
of how many items are waiting for verification
·
Made interface for working
with text and working with a style sheet consistent
·
Separated category selection
for documents from choosing whether to add, modify, or delete
a document (makes the interface more like a dialog
or series of steps that user has to go through to complete their
task)
·
Changed interface for
adding graphics so user can see all the options at one time
Navigation
Changes
·
Put additional navigation
into the system after confirming an addition, modification
or deletion has occurred to help the user determine
where to go next
·
Reduced number of options
available from the first page
Changes
we didn't have time to implement
·
Plan to rename the Editor's
console
·
Plan to add instructions
to each page to tell user what they need to do at each step
First
interactive
As
mentioned above our first interactive prototype incorporated
the changes from the low-fi test.
We then had SF MOMA do a heuristic evaluation of the
interface. The heuristic evaluation provided great feedback
about the areas of our interface that needed to change.
First
Interactive Storyboards by Scenario
First
Interactive Screenshots
Major
problems identified in the Heuristic Evaluation
Work
Flow Problems
·
The evaluators noted that
there is a lack of metadata associated with documents.
This metadata includes information like the
last author, date last modified, and category information.
Providing the metadata to users helps trigger their memory
and ensure they are working with the correct document.
· The evaluators
also noted that there was a potential to have files accidentally
overwritten because different users can work with
the same document at the same time.
·
The evaluators also noted that there is
a lack of guidance through the work-flow in the system. It is often unclear what the user
is should do on a page to complete their task. In addition, users were often uncertain about when they had
completed a task.
·
The evaluators felt that
Ezedit had many attributes that were difficult to deal with.
Also, the evaluators felt the make it live/searchable
checkbox in this section was confusing.
·
The evaluators felt that
there were not enough accelerators in the system.
For example, does the executive with Editor's Console
rights have to go to the Console to make their own changes go
live?
Feedback
Problems
·
The evaluators noted that
there was a lack of feedback within the system. For example, users cannot preview their
work. Therefore,
users do not know if they have done the right thing.
·
The evaluators also felt
that users need to know which documents are associated with
a style sheet before deletion or modification. In addition, users need to know which
documents are linked to a graphic before deletion.
Navigation
Problems
·
The evaluators also noted
that there were a lack of escapes within the system other then
the option to log out or use the browsers back button
·
The evaluators also noted
that it was important for this system to support search capabilities.
Users will not be able to recall categories
or titles of desired files and therefore will want a search
option so the can find the desired file.
·
The evaluators felt the
use of numbering for options caused the user to think that there
was a series of steps to follow
Error
Recovery Problems
·
The
evaluators also felt that the error messages need to be improved. The error messages were standard system
output rather then helpful messages that allowed the user to
recover from the error.
Changes
for the second prototype based on the heuristic
Work Flow Changes
·
Put a short description of the system on the login page and put
instructions on every page to provide more guidance in the system
·
Provide last author, last update, and category
information for documents so that metadata is carried with the document
·
Removed parts of Ezedit to simplify
·
Removed the make it live/searchable
check boxes
·
Put in confirmation pages
to help users realize that they had completed the task
Navigation
Changes
·
Added cancel button and go back buttons
to provide escapes within the system
·
Removed the numbering in places where there weren’t steps
Feedback
Changes
·
Put in a preview section for documents
so users can see how changes will look
·
Tell users which documents are linked to
a style sheet before modification
Other
Changes
·
Editors console renamed to verification
console (problem left over from Low-fi test)
·
Fixed many of the inconsistent buttons/links
(as a smaller change the evaluators mentioned we needed to be
consistent in our use of buttons/links)
Changes
we didn't have time to implement
·
Add help and documentation
·
Add search/browse features
·
Deal with issue of Verifiers having
to go to the Verification console to make their own documents
go live
·
Add a list of documents that will
be affected by a style sheet or graphic deletion before the
user presses the delete button
·
Provide protection against overwrite
·
Fix error messages
·
Remove additional unwanted features
in Ezedit
Second
interactive
As
mentioned above our second interactive prototype incorporated
the changes from our heuristic evaluation. We then did a usability test on our second
prototype. This usability
test provided more information then our low fi usability test
because the system was more interactive so the users were better
able to see how the system would fit into his/her work environment.
Therefore, the users gave us more feedback about the
problems with the system. However, our usability test was still not ideal
in that the files used in the system for the usability test
were not 'real' work files for the users.
Ideally, we wanted to install the system in a real group
web development environment and determine if the tool helped
the users complete their job. Unfortunately, we were unable to do this because
of user constraints and time constraints. However, we still
feel we gained insights from our usability study about components
of our system that needed revision.
To
view some of the screen designs after heuristic evaluation,
type in the following URL:
http://sandbox.sims.berkeley.edu:8000/cmanage2/login.cfm
Second
Interactive Summary of Changes
Major
Findings from Usability Test
Navigation
Problems
·
User wanted the option to make changes
after they preview a document. The selection of the style sheet and graphic
occurred on the page after the text entry. At this point the user can preview, but
cannot go back to the text section to make changes.
·
The button titles need to be more
useful. Most of the
buttons say submit. It
is more helpful to have titles with descriptions that express
what the user is trying to do.
·
Users wanted to have titles on the
top left of each page.
Terminology Problems
·
There
were several instances where the terms we use in the instructions
are unclear.
Instruction Problems
·
There
were several places where are instructions are unclear.
Feedback Problems
·
Users wanted a preview button on
the style sheet pages and the graphics pages (had a preview
button on documents). Users
really want to view the changes they make.
·
Users would like to know that the
verifier has been notified that something is waiting for them
in the verification console.
Work Flow Problems
·
Having
the selection of the style sheets and graphics separate from
the DEM in both working with a document and in the verification
console prevents a break in flow. The user is unsure what they are supposed
to do in the style sheet and graphic selection because
they feel they have already submitted the document to the system. The reason for this separation is due to the use
of Ezedit.
·
The verifier needs information about
who created the documents waiting in the verification console
to trigger their memory.
·
The verifier needs to be notified,
perhaps via e-mail, that something is waiting for them in the
verification console. This
email would include the name of the document waiting
and who created it.
Changes
for the third prototype based on the usability test:
Navigation
Changes
·
Changed names on buttons to be more descriptive. For example,
instead of having a 'submit' button after the user selects a
category, the button says 'select category'.
·
We added titles to each page to help users understand where
they were in the system. For example, in the adding a graphics
section it says 'add a graphic' at the top.
·
We put in titles for each of the options on the documents and
style sheet page. For example, on the style sheet page there
are now bullet points that say, "modify a document,
add a document, and delete a document" next to the appropriate
section.
Feedback
Changes
·Preview
buttons for style sheets and graphics
·After
the user submits a document for verification, the confirmation
message tells users that an e-mail about the document has
been send to the boss.
Work
Flow Changes
·
Added information about who last authored a document in verification
console
·
Put style sheet selection and graphic selection on same
page as document entry (this also alleviates the problem of
not being able to make changes after preview)
·
Verifier receives an e-mail that a document is waiting for them
in the Verification Console
·
Provide a save for later option where the user can save changes
without submitting to verifier or making live.
Terminology/Instructions
Changes
·
Fixed instructions to reflect users feedback
·
Labeled selection options as HTML site, WAP site, Flash site.
Changes
left over from the Heuristics
·
Provided a list of linked documents to graphics and style
sheets before deletion
·
Added an accelerator button for editors so they can verify without
going to verification console with go live button for editors
in documents section
·
Provided Search across a variety of attributes such as title,
author, date, category, and file type
·
Provided Help and Documentation
·
Provided Better Error Messages
·
Provided Flow Chart
·
Dealt with Overwrite Problem using locks
·
Removed Ezedit because had problems that couldn't be worked
around
Other
changes
·
Remove breadcrumb looking figure before CMS at tops of all pages
in the system
·
Made main page have buttons for consistency
Third
interactive
As
mentioned above, the third interactive prototype incorporated
the findings from our usability test. The third prototype also includes changes from the heuristic evaluation
that we did not have time to incorporate between the first and
second prototype.
We
made a lot of changes from our second prototype to our third
prototype. If we had
more time, we would conduct a usability test with these changes. In addition, we would like to conduct the ideal usability test mentioned
above in which we install the system in a real work environment.
Shortcut
back to Final Interactive Screenshots
Conclusions
Over
the course of the semester our designed progressed from rough
sketches and ideas to an interactive interface that addresses
many of the users needs. However,
there are still some issues that we have not addressed with
our current prototype. First, what do users see when they do the preview?
Do they preview the page as it would look in HTML site,
Flash site, or WAP site? Second, users may want to search for files relating to a task they
completed. Third, users
may want to apply a newly added graphic or style sheet to many
documents rather then one at a time.
Fourth there may be more than one verifier in an organization.
Therefore, users would need to choose which verifier
receives a given document for verification.
Fifth, the system does not offer protection against the
accidental deletion of graphic, document, and style sheet files.
One solution is to periodically make a back up copy of
the system, but this solution is outside of CMS.
A final issue is that it may be more natural and better
match to user's mental model if files in the system were represented
as moveable objects. This would allow users to drag and drop objects
in order to associate different files together for the website. Many of these options could be addressed with
a formal usability study. Even
though we did not have the time to address all of these issues,
we did learn a lot during the entire iterative process.
In interface design as with almost anything there is
always more to do.
Final
Prototype Demo
Instructions
In
order to run the content management system, you need to use
Internet Explorer.
To
download the files for CMS:
The
entire CMS system (Including executables and source code) can
be downloaded here.
Instructions
for installing the CMS system can be found here.