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/
signature.asc
Description: Digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
