Re: [sugar] 9.1 Proposal: Files
2008/10/30 Luke Faraone [EMAIL PROTECTED]: On Wed, Oct 29, 2008 at 20:50, Bill Bogstad [EMAIL PROTECTED] wrote: the fact that they will quickly disappear off the screen, and may be auto-deleted by the system greatly limits their value. Only if they don't get used. In which case, those entries should scroll off the bottom and get auto-deleted. The same way that email client users usually delete the 'welcome to the system' email that many systems generate. Once a user learns the basics of the activities, they will spend less and less time consulting the manual and the screen real-estate it takes up in the Journal is better suited for other things. Until they need to consult their manual, which sugar decided they didn't need and expunged. The activity itself would still be accessible from Home View, just not the dummy journal entry that would launch it... Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Files
On Wed, Oct 29, 2008 at 1:21 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: 2) Data access and user-perceived reliability: Problem: Users can't find things because they're not providing enough metadata for search to work, and there's too much stuff for them to find it without search. ... - Reduce the number of unwanted objects that accumulate - by providing a draft mode option that does not produce any object - but still produces a listing in a separate Actions view (see http://wiki.laptop.org/go/Designs/Journal) - by resuming previous instances by default, so as to encourage continued work on existing objects Alternative proposal to encourage Journal use: When the system boots, start in the Activity view with the Journal; not in the Home view. Pre-populate Journal with entries for the recently written help manual and selected (3 or 4) entries for the most commonly used/popular activities. This would emphasize the importance of the Journal in tying the whole system together. By putting the help manual at the top, I believe the discoverability of many features/activities would be greatly increased. Note: the pre-populated Journal entries would be no different then any other entry. If the user doesn't want them anymore, they can delete them without any other consequence. This is much like the initial mail messages that some mail clients use to demonstrate features to new users. Bill Bogstad ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Files
On Wed, 29 Oct 2008, Bill Bogstad wrote: On Wed, Oct 29, 2008 at 1:21 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: 2) Data access and user-perceived reliability: Problem: Users can't find things because they're not providing enough metadata for search to work, and there's too much stuff for them to find it without search. ... - Reduce the number of unwanted objects that accumulate - by providing a draft mode option that does not produce any object - but still produces a listing in a separate Actions view (see http://wiki.laptop.org/go/Designs/Journal) - by resuming previous instances by default, so as to encourage continued work on existing objects Alternative proposal to encourage Journal use: When the system boots, start in the Activity view with the Journal; not in the Home view. Pre-populate Journal with entries for the recently written help manual and selected (3 or 4) entries for the most commonly used/popular activities. This would emphasize the importance of the Journal in tying the whole system together. By putting the help manual at the top, I believe the discoverability of many features/activities would be greatly increased. the fact that they will quickly disappear off the screen, and may be auto-deleted by the system greatly limits their value. David Lang Note: the pre-populated Journal entries would be no different then any other entry. If the user doesn't want them anymore, they can delete them without any other consequence. This is much like the initial mail messages that some mail clients use to demonstrate features to new users. Bill Bogstad ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Files
On Wed, Oct 29, 2008 at 8:11 PM, [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2008, Bill Bogstad wrote: Alternative proposal to encourage Journal use: When the system boots, start in the Activity view with the Journal; not in the Home view. Pre-populate Journal with entries for the recently written help manual and selected (3 or 4) entries for the most commonly used/popular activities. This would emphasize the importance of the Journal in tying the whole system together. By putting the help manual at the top, I believe the discoverability of many features/activities would be greatly increased. the fact that they will quickly disappear off the screen, and may be auto-deleted by the system greatly limits their value. Only if they don't get used. In which case, those entries should scroll off the bottom and get auto-deleted. The same way that email client users usually delete the 'welcome to the system' email that many systems generate. Once a user learns the basics of the activities, they will spend less and less time consulting the manual and the screen real-estate it takes up in the Journal is better suited for other things. The system will have adapted to their sophistication/usage pattern. All the activities and the manual will remain available in the Home view which currently has a lot more screen space anyway. The idea is to give a nudge towards a more effective way of working with the system. Right now the Home view (activity picker) is the starting point for the system. This encourages people to start activities (creating new Journal entries) every time they want to Chat or Browse the web. If the Journal was the first screen they would have a tendency to actually reuse entries instead of creating new ones. Why wasn't a key on the keyboard dedicated to the Journal? It's currently treated as not much more important then any other Activity. I'm not sure why people are surprised that people ignore it/misuse it. As for people not bothering to change/set the name on entries. Here's another simple idea. Why not change the default name of a Journal entry to be CLICK TO NAME (localized of course)? The icons already tells you the Activity (filetype). Repeating that info as text is a waste of screen space. Bill Bogstad ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Files
On Wed, Oct 29, 2008 at 20:50, Bill Bogstad [EMAIL PROTECTED] wrote: the fact that they will quickly disappear off the screen, and may be auto-deleted by the system greatly limits their value. Only if they don't get used. In which case, those entries should scroll off the bottom and get auto-deleted. The same way that email client users usually delete the 'welcome to the system' email that many systems generate. Once a user learns the basics of the activities, they will spend less and less time consulting the manual and the screen real-estate it takes up in the Journal is better suited for other things. Until they need to consult their manual, which sugar decided they didn't need and expunged. -lf ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Files
Erik Garrison wrote: However, it is unclear how hacking is supposed to proceed within Sugar without some exposure to the underlying filesystem. Run Browse and you start with OLPC Library. Click in the location field and you see file:///home/olpc/.library_pages/index.html. Any inquisitive child is going to start exploring and wind up looking at the source for Analyze.activity/analyze.py. (I don't know how hard it would be to add syntax highlighting to Mozilla's text rendering.) Even if it is possible to do via the Terminal, we are not making it easy for users to start by providing two incompatible views on data. Yes. I can't even look in file:///home/olpc/.sugar I've had intermittent problems in the past where I'm unable to browse other directories, but this directory is hidden to Browse by design. Files? I think mankind is in the middle of a 25-year transition to versioned URIs. It's strange that viewing that source file isn't chock full of links. But I know of no O.S. that's figured it out (remember public_html directories and Microsoft's View as Web folder?) and meanwhile the Journal is an advance on a mere file system. There's no web server on the XO, so it's hard for it to figure out the URI'd future either. If I ruled the world the Journal would be reuse + extension of Firefox 3's Places feature. Places has the same history, tags, search, last viewed, description, etc.; it allows but does not require subfolders. That would be the start of the unification of browsing the web and your local work that's surely coming. Thanks for all you do. -- =S Page ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Files
I'm going to try to reword this as a list of features that would potentially be good for the XO to have, followed with a section on how Sugar currently addresses the problem, and then potential solutions, including - but not limited to - modifying the datastore to provide human-readable file names on disk, as Ben Schwartz has rephrased use filesystems. I'm doing this because I think that Erik points out some good problems to tackle in his email, and I'd like to take a moment to explore the range of possible solutions instead of framing this solely as a Filesystem Vs No-Filesystem argument. (This discussion may eventually make more sense on a wiki page.) The original email is at http://lists.laptop.org/pipermail/devel/2008-October/020692.html for reference. -Mel PS: Metaquestion - is this a helpful way of looking at things? I did this as an experiment, with much help from bemasc and Jerub over IRC, and would like to know if this actually advances the discussion. - begin reply! 1) Compatibility with existing applications Feature: Making it possible to convert Linux/X applications into Activity bundles, retaining all important functionality, without source code alterations. Current Sugar: Has a custom API for saving data that's difficult to work with (help clarifying, please - why is this hard?) Potential solutions: I've heard using a standard filesystem, Pippy does part of this already, and others... please discuss. 2) Data access and user-perceived reliability: Feature: Encourage users to add appropriate metadata (such as titles) to objects they want to save by requiring them to explicitly decline to do so. Current Sugar: Tries to do this already in practice and in future design in a number of ways - users can explicitly name and save (keep) items in their Journal, there are Journal design documents that detail separate views for looking at a history of user actions vs. finding files ( http://wiki.laptop.org/go/Designs/Journal), etc. - how can we better articular the desired feature here, using words more concrete than it should be easier? Potential solutions: Ben broke it down into complaint/solution: The complaint is that users can't find things because they're not providing enough metadata for search to work, and there's too much stuff for them to find it without search. The solution is to encourage users to provide better metadata, and reduce the number of unwanted objects that are produced. Stephen suggested that the Journal capture metadata on how long a given Activity was open as another metric to sort by. Erik's original email suggested using a standard filesystem and requiring users to manually save things with unique names (rather than autosaving). Others? 3) Resting on upstream stability: Feature: It should be possible for upstream contributors to see, at any given point in time, how features on, code in, and bugs filed against the XO trace back to the applicable things that they can fix in the standard version of their upstream project. Current Sugar: Actually, I don't know how this works at all. Have there been problems getting needed help from upstream? Why? Potential solutions: Use the standard versions of upstream projects without modification. Others? 4) Collaboration Feature: Provide a standard mechanism for Activity collaboration between an XO and another computer not running Sugar. Current Sugar: Install Sugar on the other computer and use Jabber to collaborate. (Time-consuming, and not always possible given time and privilege constraints on the non-Sugar computer.) Potential solutions: Use standard non-Sugar-to-non-Sugar computer collaboration systems, including thoes based on file-based asynchronous collaboration. Make cross-platform non-Sugar versions of Sugar Activities (and a script to autogenerate these from native-Sugar Activities) that can somehow collaborate seamlessly with XOs. Others? 5) Hackability Feature: Indicate how an Activity's functionality and the objects it creates in the Journal map to editable source code files on the XO. This indication should be shown directly in the Sugar GUI for an Activity and also when a user is viewing source code for that Activity. (This can probably be phrased much more coherently. Help?) Current Sugar: There are currently two views that coders have to switch between; the underlying filesystem with .py files in nested and named folders, and the Journal view for the same Activity, which does not (afaik) expose a way to get into the source code through the GUI. (Exception: if you hit the view source key for Chat, one file of the Chat code opens in Pippy and is editable. Even for this, though, if you want to edit other Chat files, you have to navigate the filesystem.) Potential solutions: Have them be the same view. Others? 6) System modularity Feature: Code modules and applications that save objects should be decoupled from code modules and applications used to search and index
[sugar] 9.1 Proposal: Files
By reintroducing the concept of files to our systems we can simplify our work in a number of areas relative to 8.2: - Compatibility with existing applications: One of the principal reasons that the tens of thousands of open source applications that run on Linux aren't usable under Sugar is that we have a custom API for saving data. To make them usable we have to exert developer effort for every ported application. This does not scale and is not sustainable as we are completely alone in this effort. Furthermore, reintroducing files to our APIs will simplify the process of running Sugarized apps in non-Sugar environments, and provide consistency to users who use them both within Sugar and outside. - Data access, user-perceived reliability: Using files forces users to be intentional about saving data (they must name their work). This makes it easier for them to find things they care about--- provided, of course, that they are taught how to save files as students are in virtually all computer-based education. - Resting on upstream stability: Files are used virtually everywhere else in the computing world, and most certainly in our upstream distributions. Using files means we have the same problems as upstream, and no more. If there is a filesystem integrity problem in the Linux kernel filesystem drivers we can more readily expect the aid of upstream users and developers in resolving the issue than we could expect such aid in the case of a custom data storage system. - Collaboration: Many collaboration issues could be resolved by exposing file-based asynchronous collaboration to users. Files are the core component of collaboration in every other computing environment in common use. Using them as a primary storage system will greatly simplify the process of sharing between an XO and a non-XO. - Hackability: From the beginning of this project there has been a lot of hype about the hackability of the system (Sugar) relative to other computing environments. Python was chosen as a programming language for the environment because of its legibility and ease of use, and we are still supporting it for this reason. However, it is unclear how hacking is supposed to proceed within Sugar without some exposure to the underlying filesystem. Even if it is possible to do via the Terminal, we are not making it easy for users to start by providing two incompatible views on data. - System modularity: Files are a common abstraction which allows the interaction of any applications which can do file I/O. Using user-named files as a base-layer storage system, and not a database or hash-based file naming scheme, allows us to decouple the application which saves data from those that are used to search and index it. I propose that 9.1 include a very simple (perhaps default) way to save files to the user's home directory, and that it also include a file manager skinned or redesigned to work well within Sugar. The most reasonable thing may be to simply save files into the user's home directory if the user explicitly names/saves their work in a given application. Sugarized apps which use the Sugar Activity API can be trained to auto-save files into an auto-save directory of some kind, from which data is eventually deleted if it is never accessed again by the user or tagged/named. Auto-saving seems to be a very important feature for kids--- but so is intentional saving, as it is a common feature on every computing environment in common use and consequently has great educational importance. To provide coherent access to these files we can index them and use the Journal or a compatible index browser for search and data access. I further propose that we use a webserver with a directory listing to enable asynchronous, file-based collaboration between any two XOs on the same network [1]. Doing such would also enable collaboration between XOs and non-XOs. If we want to enable a more interactive collaboration system of this nature we can investigate the use of WebDAV or an equivalent system. I also propose that to enact this solution we relax the security system which is used to sandbox applications running on Sugar. There are certainly ways to keep the security system and enable the use of files, but all of them are by definition more complicated from a development standpoint than relaxing the security system and simply letting applications write to user-owned directories. Erik [1] http://lists.laptop.org/pipermail/devel/2008-October/020660.html ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
