View page Vs. Edit Page

14 Mar 2005 - 3:07am
9 years ago
8 replies
598 reads
sudhindra
2004

Well, actually it is like this... There is an edit icon on clicking of which
a page opens where comments can be entered/edited. When the user has to just
see it and not really edit it, is it advisable to give another icon on
clicking of which a page opens only for "viewing" and not for editing ??

Not only in this context but for many admin sections as well, such as a
profile page, where data can be entered/edited and also if the user wishes
to only see them and not really edit them, is it advisable to give two
different links - one for view and another for edit???

I am of the view that a single page for edit should do for both..... i.e.
the edit page itself should be used in case the user wants only to view....

Best Regards

Sudhindra

Comments

14 Mar 2005 - 4:07am
Ben Hunt
2004

I see a couple of routes here, depending on the workflow. I think it
depends on how much of a barrier you need between Edit / View modes.

1) If you need 2 clearly different modes: View mode and Edit mode, then
the important thing is that those modes are clearly differentiated. i.e.
You're never in any doubt whether you're in Edit or Non-edit. The driver
for this would usually be to prevent accidental editing of data. In this
scenario, having a page reload is a small step that provides a pause,
which may be useful as a further soft barrier.

2) If the workflow is such that Edit is the default mode (i.e. this user
is an Editor, who can browse and edit freely), then perhaps you don't
need much of a barrier. In this case, it's arguable that Edit could be
the one and only mode. Or - you may want a very soft barrier, a toggle
between the two, in which case you probably don't want a page reload.

- Ben

Sudhindra Venkatesha Murthy wrote:

>[Please voluntarily trim replies to include only relevant quoted material.]
>
>Well, actually it is like this... There is an edit icon on clicking of which
>a page opens where comments can be entered/edited. When the user has to just
>see it and not really edit it, is it advisable to give another icon on
>clicking of which a page opens only for "viewing" and not for editing ??
>
>Not only in this context but for many admin sections as well, such as a
>profile page, where data can be entered/edited and also if the user wishes
>to only see them and not really edit them, is it advisable to give two
>different links - one for view and another for edit???
>
>I am of the view that a single page for edit should do for both..... i.e.
>the edit page itself should be used in case the user wants only to view....
>
>Best Regards
>
>Sudhindra
>_______________________________________________
>Welcome to the Interaction Design Group!
>To post to this list ....... discuss at ixdg.org
>(Un)Subscription Options ... http://discuss.ixdg.org/
>Announcements List ......... http://subscribe-announce.ixdg.org/
>Questions .................. lists at ixdg.org
>Home ....................... http://ixdg.org/
>
>
>

14 Mar 2005 - 6:27am
Patricia Mullenberg
2005

I agree with Ben.

>From what I can tell it isn't critical that stuff isn't edited
accidentally, in which case it would be more efficient if the user can
edit by default. My only two considerations would then be that it is
clear to the user that the text is editable and that he can undo edits
if they are accidental.

Cheers
Trish

Sudhindra Venkatesha Murthy wrote:

>[Please voluntarily trim replies to include only relevant quoted
material.]
>
>Well, actually it is like this... There is an edit icon on clicking of
which
>a page opens where comments can be entered/edited. When the user has to
just
>see it and not really edit it, is it advisable to give another icon on
>clicking of which a page opens only for "viewing" and not for editing
??
>
>Not only in this context but for many admin sections as well, such as a
>profile page, where data can be entered/edited and also if the user
wishes
>to only see them and not really edit them, is it advisable to give two
>different links - one for view and another for edit???
>
>I am of the view that a single page for edit should do for both.....
i.e.
>the edit page itself should be used in case the user wants only to
view....
>
>Best Regards
>
>Sudhindra
>_______________________________________________
>Welcome to the Interaction Design Group!
>To post to this list ....... discuss at ixdg.org
>(Un)Subscription Options ... http://discuss.ixdg.org/
>Announcements List ......... http://subscribe-announce.ixdg.org/
>Questions .................. lists at ixdg.org
>Home ....................... http://ixdg.org/
>
>

14 Mar 2005 - 6:49am
Jon Antin
2005

I believe a View-only Page is often required, separate from an edit page. It strictly depends on the nature of the data, but it does provide several advantages:

1. It minimizes the chance for inadvertent changes being made to the data, especially when the data are of a critical nature (as they often are).
.
2. If makes it easier for the user to see/confirm that intentional changes were made and made properly when the user is returned to the updated View-Only page after a save.

3. Also, don't minimize the fact that it is often beneficial to have two different page formats depending upon whether the data are in View-only vs. Edit mode. For instance, a name can be presented as a unified field: "John H. Smith, Ph.D." on a view page (if not part of an alphabetically ordered list), but it would usually need to be presented as 4 distinct fields on an edit/update page.

Jon Antin
NC A&T SU

Hi there everyone,

Is it better to use a edit page as also the view page? Or is it more
usable
to provide a different view page so that a user clicks on two different
links to access Edit and View page differently?? Any ideas??

Sudhindra

---------------------------------
Do you Yahoo!?
Make Yahoo! your home page

14 Mar 2005 - 7:12am
Dave Malouf
2005

> I believe a View-only Page is often required, separate from
> an edit page. It strictly depends on the nature of the data,
> but it does provide several advantages:

The problem comes when trying to communicate this concept to users. The
concept of "View/Edit" is a tricky one to communicate to users in a manner
that will consistently match up against mental models and task flows. Having
designed a Content Management System I can tell you that the "good" reasons
for doing this level of separation and the difficulty of making this
separation useful and usable to the end user.

Addressing the specific issues raised below:

> 1. It minimizes the chance for inadvertent changes being made
> to the data, especially when the data are of a critical
> nature (as they often are).

There are other ways to do this in a single view format.

> 2. If makes it easier for the user to see/confirm that
> intentional changes were made and made properly when the user
> is returned to the updated View-Only page after a save.

Again, there are other ways to do this. An example would be to show the
current values next to editable fields. If the field is filled it will be a
change, leaving it blank will make no change. When you click save, make the
last changes distinguishable by color or form and allow for an "undo" button
of some kind through version and history management.

> 3. Also, don't minimize the fact that it is often beneficial
> to have two different page formats depending upon whether the
> data are in View-only vs. Edit mode. For instance, a name
> can be presented as a unified field: "John H. Smith, Ph.D."
> on a view page (if not part of an alphabetically ordered
> list), but it would usually need to be presented as 4
> distinct fields on an edit/update page.

Outlook has a great example of getting around this issue. Where by there are
single edit views for name, address, phone number and even e-mail. It does
validation against the field. If that validation doesn't match as necessary
it pops open a full fledged form for editing that area in more distinct
broken down fields.

And before someone says, but that is a desktop app, there is nothing of what
I just described that can't be done in a web app.

The one reason that wasn't mentioned and IMHO is still not necessary (or
more accurately, the benefit/harm ration still not worth it) is this notion
of "locking" the item so others can't do an edit the same time you are.

Even this is not necessary, as you can do the lock at the moment of save and
b/c the Web is in such a stated environment, if someone tries to save data
back that is out of date, you throw an exception and give the user another
chance to try again, after you show a comparision of old and changed fields
and what you entered. THIS is a web-problem b/c of the stated nature of the
web. I'm not even sure an AJAX version of HTML or a Flash/Flex version of
your app would get around this one.

Now there is another ratio that needs to be considered as well. That is the
cost/benefit ratio. How much will this cost to make easier for the user vs.
how much easier is it really making it for them. To do a system well like
this requires a lot of both design and engineering time and when you get to
this level of complexity it is more important to get it right.

-- dave

14 Mar 2005 - 4:50am
Abhishek Thakkar
2004

You can also check out the TextPattern Style...
which follows the "Code"(edit) "Design" (View) and "Mix" (Both) modes
in input as tabs. It gives you an option of Live Preview w/o reloading
the page and there is a Submit button seperately positioned to press
when you are satisfied with the post. I personally find this quite
useful, not sure about the common user.

You dont have to install Textpattern for checking it out. Free demo
admin panel of Textpattern and many other OpenSource CMS are available
at:

http://www.opensourcecms.com

-Thakkar

14 Mar 2005 - 9:15am
Todd Warfel
2003

Yeah, like edit w/live preview. That helps accomplish both.

On Mar 14, 2005, at 7:12 AM, David Heller wrote:

> There are other ways to do this in a single view format.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
MessageFirst | making products easier to use
--------------------------------------
Contact Info
V: (607) 339-9640
E: twarfel at messagefirst.com
W: messagefirst.com
AIM: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

14 Mar 2005 - 10:02am
Coryndon Luxmoore
2004

Sudhindra wrote:
>I am of the view that a single page for edit should do for both..... i.e.
>the edit page itself should be used in case the user wants only to view....

The way I figure out whether or not to use the same page to consider a
couple of paramenters:

- Is the place that you edit different from the place it makes sense to
view?

Example: When I am filling out a form and submit it I may need to confirm
it's contents are correct so it is critical I recognize that the response is
for review not just a system error representing the same form.

- Is the way the data is entered different from the ideal way of viewing it?

Example: In applications where you fill out the address it may be desirable
to have the country as the first address field so that the application can
display the appropriate address format based on the country foe which you
are entering the address. However, from a display perspective it is better
to format it in the way that it would appear on the label or a package

- How familiar is the user with the application?

Example: If you are working on an application that people are using as a
primary application they will be more tolerant of non standard presentation
if it benefits them from an efficiency perspective. They will "know" where
to look. People who are only using the application occasionally will rely on
outside conventions to help them validate and read the displayed
information.

--Coryndon

14 Mar 2005 - 11:35am
John Vaughan - ...
2004

Use cases, permissioning & security often define whether or not a given individual has the ability to "view" "edit" or "create" a record.

>From a workflow perspective, you can keep things "cleaner" (less backend conditional programming, less screen clutter) by separating View and Edit.

Syndicate content Get the feed