[Sugar-devel] UI mockups for version support in Journal
Sascha Silbe
sascha-ml-ui-sugar-devel at silbe.org
Wed Apr 22 04:49:14 EDT 2009
On Fri, Apr 17, 2009 at 02:06:55AM +0200, Sascha Silbe wrote:
[Mockups]
> The second one [2,3] modifies the date field to be a combo box, like
> shown in Journal Designs #12 [4].
The fine thing with mockups is that they show just what you imagine, not
the complicated reality.
How do we actually handle branches?
Option 1:
* show all versions in the branch of the current entry, including all
ancestors on "super" branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1,
1.1, 1])
* rebuild the date/version box on selection of a version
+ consistency: no matter how you got to the current version, it will
always look the same
- oneway: once you select a version on a "super" branch, you're stuck to
it and can't change back to the originally chosen version anymore.
Option 2:
* show all versions in the branch of the current entry, including all
ancestors on "super" branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1,
1.1, 1])
* always show the date/version box of the originally selected version
+ oneway: you can go back to the originally selected version from any
ancestor
- consistency: depending on where you entered the tree, you'll get
access to different versions.
Option 3:
* only show direct linear ancestors, not "super" branches
+ no consistency or oneway issues
- no access to earlier branches, i.e. any load+save of a non-HEAD
version will cut the entire ancestry for the just saved version
Option 4:
* flatten and sort the entire version tree according to the date
+ no consistency or oneway issues
+ access to all branches/versions
- no information about ancestry, an intermediate version might lack
content that both "neighbors" (in the list) have
Thinking about it, Option 4 is probably the way to go for now (unless
someone can come up with a smart #5). Rely on the user to tag the
documents well enough to avoid confusion. We probably want to revise
this decision later when we got some experience with actual user
behaviour.
CU Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090422/cd2885d9/attachment-0001.pgp
More information about the Sugar-devel
mailing list