self-platform-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Self-platform-dev] Re: [teg] SELF Lesson v6 & v6a, versioning


From: Wouter Tebbens
Subject: [Self-platform-dev] Re: [teg] SELF Lesson v6 & v6a, versioning
Date: Wed, 23 Jan 2008 11:28:10 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20071008)

Dear Niyam,

Especially the changing from one branch to another is something that intrigues me. The branches include a lot of information that somehow we need to provide in a clear way as to support the user in making a decision to change from one to another. As a user I would like to know what's the difference between them. I might want to change to another branch and continue working from there, or I might want to merge two branches into one. A tree overview of how branches relate might be helpful. Although "tree" is not the best methaphor I think, as a tree doesn't have merged branches normally :)

Just to illustrate the production process I posted an example of a possible eveolution of some versions a few months ago. Here you have it again, let me know how you think we could facilitate users whith this.

Best,

Wouter

Federico Heinz wrote:
On 22/01/2008, niyam bhushan wrote:
[v6]
[...]
[v6a]

I really suck at "find the seven differences". In this case, I can't see any
difference at all between v6 and v6a. It's not that it's not there... it
probably is, I just can't find it.

As to the proposed versioning interface, I have a few comments:

1. There is provision for offering feedback on popularity/quality assessment
   rating of each version.
2. Version numbers growing from right to left is a bit odd for westerners,
   so this should be part of the locale setting.
3. The proposed view at the bottom acts as a breadcrumbs path along the
   document's history, and as such it satisfactory (showing the answer to "how
   did I get here?"). It doesn't work as well for newer versions than the
   selected one: how do we show the user which neweer versions are available?
   In particular, keep in mind that a linear view of newer versions is not
   acceptable. For the past, it's OK because the user has chosen one particular
   path already, so showing alternative branches is not a priority. But when it
   comes to newer branches, we cannot assume that the user will select any one
   of them, so we must show a tree, not a list.
4. Since we have a tree structure, I don't know whether numerical version tags
   make much sense as they may only reflect the temporal sequence, not the
   history. This means that v100 and v101 may be in completely different
   branches, and thus have very little in common. I am still trying to figure
   out what would be a useful way to tag versions from a user's perspective,
   independently of the way how it is implemented in the back-end.
5. There is no provision in the UI to change the selected version to a
   different one.
6. I see no way in the UI to see the differences between two versions.

General comments, because they apply to all of our UI:

1. I know that graphic designers *love* to leave wide margins around
   everything, but I fear that we are being way too generous with the user's
   screen's real estate. Granted, all those gray pixels around the work areas
   are pretty, but I fear that many users would prefer us to use them to show
   more of the content they are looking at.
2. The UI layout looks pretty in the 16:9 aspect ratio, and certainly is more
   than OK in the widescreen configurations most of us are privileged enough to
   use, but does it scale well to lower resolutions and 4:3 aspect ratio, which
   is still widespread?

        Fede


------------------------------------------------------------------------

_______________________________________________
teg mailing list
address@hidden
http://mail.selfproject.eu/mailman/listinfo/teg

Attachment: SELF_version_control.odg
Description: application/vnd.oasis.opendocument.graphics


reply via email to

[Prev in Thread] Current Thread [Next in Thread]