[Bugs] #3209 UNSP: Journal should support display of activity-specific metadata

[Sugar Labs Bugs]

#3209: Journal should support display of activity-specific metadata
------------------------------------------+---------------------------------
    Reporter:  walter                     |          Owner:                             
        Type:  enhancement                |         Status:  new                        
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by Release Team
   Component:  journal                    |        Version:  Unspecified                
    Severity:  Unspecified                |       Keywords:                             
Distribution:  Unspecified                |   Status_field:  Unconfirmed                
------------------------------------------+---------------------------------
 Long discussion but the conclusion is that we should have some mechanism
 on an activity by activity basis of displaying metadata in the Journal
 above and beyond the standard ExpandedView. Either a metadata or
 activity.info field to indicate what additional metadata to display (and
 whether or not it is editable)

 The mock-up (http://wiki.sugarlabs.org/go/File:TAtags.png) is not correct
 because it overrides the tags field.

 ---
         <ClaudiaU_>     hello
         <walterbender>  hi
         <gonzalo>       hello
         <walterbender>  let me try to summarize where I think we are to
 start
         <walterbender>  there is interest in tags (automated and user-
 supplied) by the Learning Team
         <walterbender>  there is the possibility of activity-generated and
 sugar-generated tags
         <walterbender>  there are outstanding UI issues
         <walterbender>  and some backend issues
         <walterbender>  I have a simple proposal to start
         <walterbender>  to augment the tags field in the journal detail
 view
         <walterbender>  to leave the tags field as a place for freeform
 keyword entry and to drag and drop predefined tags
         <ClaudiaU_>     correct
         <walterbender>  and to have a separate mechanism/display of
 program and usergenerated keyword-value pairs
         <walterbender>  the freeform field is not useful to me as an
 activity developer because:
         <ClaudiaU_>     when we had the conversation this morning, the
 members of the community didn't really know that the tags could be use for
 that purpose
         <walterbender>  I need something I can parse so, for example, I
 can add to or change a tag value
         <walterbender>  so I would rather exploit the existing metadata
 dictionary
         <ClaudiaU_>     agree
         <walterbender>  but to do so, I need a ay in the UI to display
 these values
         <walterbender>  gonzalo: how about I mock up something for
 discussion at the next design meeting?
         <gonzalo>       walterbender: yes, i think is the way to go
         <walterbender>  gonzalo: OK... I think it will be pretty simple to
 implement... although I can imagine lots of corner cases
         <gonzalo>       i agree with you about using defined tags and not
 freeform
         <walterbender>  gonzalo: but metadata['tags'] is freeform
         <gonzalo>       walterbender: yes, right now
         <walterbender>  gonzalo: and metadata['anything else'] is
 invisible to the user
         <gonzalo>       yes
         <gonzalo>       walterbender: yes, we need improve it
         <gonzalo>       i can't find the proposal we worked in edujam
         <walterbender>  so I see two different approaches: (1) make the
 value of tags a Python dictonary or (2) ignore it and use the metadata
 dictionary we already have
         <walterbender>  gonzalo: this is independent of where tags come
 from
         <ClaudiaU_>     I need to understand some implications
         <ClaudiaU_>     would the tags be changable?
         <ClaudiaU_>     so imagine I create a TurtleArt project, like the
 one you created walterbender, and I go to the journal...
         <ClaudiaU_>     would I see those tags and be able to change them?
         <walterbender>  ClaudiaU_: I think we want to make them changeable
 in general
         <gonzalo>       ClaudiaU_: depends of the use we want to do
         <walterbender>  maybe some protected tags
         <gonzalo>       maybe the tags can be editable
         <ClaudiaU_>     I think there should be ones not editabl
         <ClaudiaU_>     editable..
         <gonzalo>       and we have other metadata , like "how much time
 the kid used the activity " not editable
         <ClaudiaU_>     I would like to keep the once that the Sugar
 Activity is going to generate
         <gonzalo>       but that is metadata, no tags
         <ClaudiaU_>     but would the metadata be visible?
         <ClaudiaU_>     in the journal?
         <walterbender>  ClaudiaU_: I think it should all be visible
         <gonzalo>       ClaudiaU_: may be we need first define what data
 we are interested in generate
         <ClaudiaU_>     agree, walterbender!
         <gonzalo>       and later define what is editable and what no
         <walterbender>  ClaudiaU_: but maybe the distinction between
 editable and uneditable is to be determined from a UI perspective
         <ClaudiaU_>     gonzalo, yes, we are in the process of the
 defining what data in each Activity
         <ClaudiaU_>     +1 walterbender!
         <walterbender>  gonzalo: I could imagine an activity marking which
 tags are visible and which are editable,
         <walterbender>  in the form of another tag :)
         <ClaudiaU_>     I just imagine that the child will be motivated to
 add any tag, inspired by the ones he sees (generated) and then the tags
 may not represent what the project really is
         <walterbender>  ClaudiaU_: remember we still have the description
 field and the freeform tag field as well
         <gonzalo>       ClaudiaU_: but now, the tags are not useful,
 because we can't filter in the journal en a easy way
         <gonzalo>       if we have aa good filter using tabs
         <gonzalo>       and may be using to activities like Portfolio
         <gonzalo>       then the tags will be more useful
         <ClaudiaU_>     I agree
         <ClaudiaU_>     a lot of things are not useful, even when they
 work because people don't know about its use
         <gonzalo>       like
 http://wiki.sugarlabs.org/go/Journal_NewUI#Mockups
         <gonzalo>       i found it :)
         <gonzalo>       the idea of this design is do the tags more
 visible and useful
         <walterbender>  gonzalo: maybe we need two mechanisms: tags and
 keyword/value pairs
         <gonzalo>       walterbender: the metadata is already a key/value
         <walterbender>  gonzalo: yes... but it doesn't show up in the UI
 anywhere (except a few select fields)
         <walterbender>  gonzalo: let me put it a different way...
         <gonzalo>       walterbender: can you show me a example of
 key/value needed data?
         <walterbender>  in the example from TA, we want a tag for each
 block type a child uses, so we can monitor how complex their projects are
         <walterbender>  in the mockup, that would mean perhaps 100 tags
         <walterbender>  gonzalo: that tagging mechanism UI is not meant
 for that volume of tags
         <walterbender>  gonzalo: so I was thinking of an activity-specific
 tag field.
         <gonzalo>       walterbender: hmm, maybe is better have a
 complexity field, and turtleart calculate it
         <walterbender>  gonzalo: but I don't want to reduce my complexity
 metric to 1 value
         <gonzalo>       walterbender: i think we have a text field in the
 metadata, you can save the program in logo in it
         <walterbender>  gonzalo: the bottom line is that I need a
 structured mechanism in the journal with an associated UI
         <walterbender>  and the mockup only addresses part of that problem
         <gonzalo>       walterbender: anyway, if every activity can save
 any data (and you are talking about hundred of values) we will not find a
 way to show that
         <walterbender>  gonzalo: I think we haven't looked for one yet...
 so I am not ready to give up
         <gonzalo>       :)
         <walterbender>  gonzalo: I think the EduJam mockups serve a
 purpose, but we have other needs too...
         <gonzalo>       walterbender: yes, i understand
         <walterbender>  gonzalo: I just want to eliminate redundancy of
 effort if we can
         <ClaudiaU_>     no giving ups!
         <gonzalo>       i think there are two different use cases, tags,
 and metadata, at times will be the same, and at times no
         <gonzalo>       ClaudiaU_: we need prepare a good proposal
         <walterbender>  gonzalo: what I think I will mock up for the
 short-term is a way of displaying arbitrary metadata in the ExpandedEntry
 view
         <gonzalo>       the design team is very active and will help
         <ClaudiaU_>     walterbender: in the case of turtleart, you are
 thinking a tag, per block and keep the frequency of the block, right?
         <gonzalo>       he he :)
         <walterbender>  gonzalo: perhaps an activity can set a field that
 says which metadata to display
         <gonzalo>       walterbender: yes, or can be a configuration in
 activity.info
         <ClaudiaU_>     and only create a tag for those blocks that are
 parsed and that work?
         <ClaudiaU_>     what if the block are floating around with no
 purpose?
         <walterbender>  gonzalo: yes... there as well, but I don't know if
 those data are available in the ExpandedEntry view
         <gonzalo>       walterbender: ClaudiaU_ show why is more complex
 than only a list of values :)
         <walterbender>  ClaudiaU_: one step at a time :)
         <ClaudiaU_>     I am already going ahead with possibilities
         <walterbender>  ClaudiaU_: the kids will be able to spoof it, but
 I can imagine: show me a project where you used the repeat block and
 finding it with a simple Journal search
         <ClaudiaU_>     that would be great to do
         <gonzalo>       ClaudiaU_: would be good if you think in more
 general cases, not only turtle art. there are other activities too :)
         <walterbender>  ClaudiaU_: with what I already implemented, you
 can do that now :)
         <ClaudiaU_>     yes!
         <ClaudiaU_>     I will talk to Melissa and we will have the table
 with all the activities and we will start a brainstorm process
         <ClaudiaU_>     hopefully other learning people will join
         <gonzalo>       great
         <walterbender>  gonzalo: are there any tickets associated with the
 EduJam mockups?
         <walterbender>  gonzalo: because I was going to open one and past
 in this conversation
         <gonzalo>       i should check
         <gonzalo>       ClaudiaU_: we are in a good moment, if we want
 propose changes should be before Dec 5
         <gonzalo>       (if we want have it in the next version)
         <gonzalo>       http://wiki.sugarlabs.org/go/0.96/Roadmap#Schedule
         <ClaudiaU_>     will work towards that.. promise!!
         <gonzalo>       walterbender: we should prepare a Feature proposal
         <walterbender>  gonzalo: yes... but I will make a ticket as a
 placeholder for the moment
         <walterbender>  gonzalo: I think we want to implement both the
 EduJam tags and the Activity tags
         <gonzalo>       yes
         <ClaudiaU_>     I will keep you in the loop.. we will put the team
 to work
         <ClaudiaU_>     with the deadline in mind

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/3209>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system