[Sugar-devel] Library-1 Feedback

[Aleksey Lim]

On Tue, Jun 02, 2009 at 10:50:26AM -0500, James Simmons wrote:
> Aleksey,
>
> I was eager to try your Library activity but I couldn't get to it until  
> last night because my XO is running .82.  I had to use SoaS to bring it  
> up.  I have to say it's a good first effort at this and I was impressed.  
> I think it will be a valuable addition to Sugar.  Now the feedback:
>
> 1).  There is a bug in the Description field when you View Details for a  
> Journal entry.  I found this out when I placed a Description for Volume  
> 9 of the Works of Jules Verne.  The description read "Off on a Comet!",  
> the name of the novel in Volume 9.  After that it seemed like *every*  
> Journal entry had that description.  So that needs checking out.
thanks, I hope I fixed it

> 2).  I like the tagging mechanism pretty well, and I like that there is  
> always an attribute for Author plus any number of tags that can be used  
> for any purpose.  I was surprised that the "Tags" do not seem to be  
> stored in the "tags" meta data in the Journal.  I had modified Read  
> Etexts to store the author name of a downloaded book in that field,  
> thinking that when the Library activity was ready all the downloaded  
> books would be pre-tagged.  It didn't work that way.  I still like the  
> idea of having books downloaded through Read Etexts be pre-tagged with  
> at least Author, and possibly things like Subject, Language, etc.  I'll  
> have to look at the source of your Activity to see how to make that  
> possible.

The problem is - user can use any symbols in tag name(including spaces)
at the same time Library needs datastore to make exact query by this
tag and do not mess tag name with words in description field for example.

So Library stores tags in json string with structure:
[("pretty-tag-name", "__tag_name_especially_to_make_exact_query__"),..]
thats why this string goes to "_tags_" field and not to "tags".

About author names Library uses additional fields for that reason:
http://git.sugarlabs.org/projects/library/repos/mainline/blobs/master/source.py#line79
because they appear in list view and should be sorted.

I guess we will standardize these fields for 0.86 and you can use them
in Read Etexts.

> 3).  In a previous email I confessed to not knowing what a "tag cloud"  
> was.  Now that it has been explained I've been seeing the damned things  
> everywhere.  I even saw one at a meeting for my own company.  I like  
> yours, with some reservations.  My problem is you use the Activity  
> bundle id as a tag.  If I have a Library full of downloaded ebooks I'd  
> expect the largest tags to be the author with the most titles, the  
> subjects with the most books, maybe if I had comics in there I would  
> have a big tag saying "Comics".  In your cloud the biggest font will  
> always be for the bundle id for Read Etexts.  I can already filter the  
> Journal so it only shows Read Etexts entries, so I don't really need to  
> do that for Library.  Personally, I'd leave these bundle ids out of the  
> cloud.  I notice you also have MIME types in there, or at least I saw  
> the word "zip".  I wouldn't think that those would belong either.

Yes, thats the problem.
I'm thinking about moving traits like author, genre,..(and maybe MIME
type) from Traits tab to new tab on tags sidebar, so user would see only
these fields in tag cloud.

But it has negative side - increased number of tabs:
* grouping objects by activity_id
* by MIME type
* traits like author, genre(that appear as columns in list view)
* users tags
* share users - to view objects that were shared by particular user
* by remote sources (sugar and non-sugar users)

> 4).  In previous emails I had wished for a way to mark individual  
> Journal entries so they would open by default with either Read Etexts or  
> View Slides.  Over the weekend I learned a lot about how Journal entries  
> are created and realized that I didn't need the Journal to do this for  
> me.  My Activities could do this for themselves, while still allowing  
> other Activities to open their Journal entry by MIME type.  Your  
> Activity lets me organize my Journal entries in ways the Journal can't,  
> making a lot of the discussion we had about the Journal last week moot.   
> I'm looking forward to the version of your Activity that runs on .82.
>
> 5).  I know this version doesn't support sharing yet, but I'm curious  
> how you will indicate that a Journal entry is eligible to be shared.

Home button(at the bottom-left corner) has content menu which allows user
to setup "root" path, so user can:
* change "root" path for all objects
* enable any tags
* setup selected tags as a new root

The whole final list will be shared for joined users.

> 6).  I think this Activity will need a Tutorial of some kind built into  
> it.  I don't think a person seeing this Activity for the first time will  
> understand what it is for and how it works.  Your user interface is OK.   
> It's just the idea of the Activity is a bit sophisticated to be grasped  
> by a first time user.

Well, true
I'm going to do something for first "user friendly" release.

> James Simmons
>
>

-- 
Aleksey