#7559 NORM 8.2.0 (: Saving and Loading of Project with sub-Projects
Zarro Boogs per Child
bugtracker at laptop.org
Sat Jul 26 17:15:50 EDT 2008
#7559: Saving and Loading of Project with sub-Projects
Reporter: dmoco | Owner: etoys
Type: defect | Status: new
Priority: normal | Milestone: 8.2.0 (was Update.2)
Component: etoys-activity | Version: not specified
Resolution: | Keywords: project save load
Next_action: never set | Verified: 0
Blockedby: | Blocking:
Just to reiterate what I have said recently on the mailing list, I am
looking generally at things from the POV of a new users, what may/ may not
be reasonable expectations and also consistency of functionality. Or put
another way, any gotcha's they may encounter. I just want to make clear I
am not taking a swipe at the decisions and effort you guys make and I
fully appreciate that your priorities are children, education and the XO.
Personally I am extremely grateful for all you have done and are doing.
And feel free to shoot down any of my assumptions, which I fully accept
may be wrong. So with this in mind...
- Assumption: a new user is not expected to use the World menu (or by
implication the "projects" menu/s). This is based on the fact that the
World menu only appears accessible through alt-W. I know many/all things
are configurable but I am assuming this is intentional on your part. If
true I am not disagreeing with this!
- Novice users are expected to navigate projects using project-view morphs
and the "back" button in the Sugar nav. As a consequence they have no
direct access to the project hierarchy and cannot jump indiscriminately
from one project to another.
- New projects can only be created from the "Etoys Activity" project.
Intentional? Means users cannot create their own hierarchies. IMHO
creating hierarchies is something that should be possible even for a
novice and emphasised as good way of organising ones activities
(even/especially where children are concerned).
- I can see the potential for tangled hierarchies and the implications if
saving of sub-projects was to be implemented (but not insurmountable). I
assume there would be other issues related to where projects are stored/
- When saving a project that contains sub-projects, there is nothing to
indicate that the sub-projects will *not* also be saved. Maybe a pop-up
- In etoys-dev it is not possible to delete a project containing sub-
projects and there is a pop-up msg to this effect. There is no such
restriction or msg in etoys-image-and-pr where the user is simply warned
that *all* project contents will be deleted, except this is not true...
- In the case of sub-projects they are not deleted and are instead re-
parented to their grandparent but now do *not* have any project-view
icons. End state being that these project/s are now effectively invisible
to the novice and also still consuming resources that the user will be
- If the user deletes a parent project *without* deleting sub-projects:
reloading parent does not re-parent children, although project-views in
parent still function as expected. Remember I am just stating my findings
and in this case before I was aware that saving hierarchies is not
- If the user deletes sub-projects before reloading parent: after
reloading parent and clicking on a child project the hierarchy is re-
established. As expected but still different from previous scenario. A
minor issue here is before a sub-project is actually loaded the balloon
help says "...(on server)" which is not true when only stored locally.
Also begs the question (most likely due to my own lack of knowledge) about
how local/server-based mechanism works? For instance: same-named
local/remote projects supported and if so do I have a choice?
To state my own preference, I would like to be able to save a project
hierarchy in one go and I believe this is what others would expect to be
able to do.
Sorry if this reply was longer than expected :-)
Ticket URL: <http://dev.laptop.org/ticket/7559#comment:6>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs