Opened 12 years ago

Last modified 10 years ago

#3209 new enhancement

Journal should support display of activity-specific badges

Reported by: walter Owned by:
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Sugar Version: Unspecified
Severity: Unspecified Keywords:
Cc: godiard Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

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 metadatatags? is freeform
<gonzalo> walterbender: yes, right now
<walterbender> gonzalo: and metadataanything 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

Change History (8)

comment:1 Changed 12 years ago by walter

Here is a sketch: http://wiki.sugarlabs.org/go/File:ActivityData.png

From TA, I created two metadata entries: 'turtle_blocks' and 'activity_data'. The activity_data field is a json-encoded list of metadata entries to display in the Journal detail view. In that view, I display the tag name and the values as a keyword-value pair.

Questions: should any of this be editable? where should they be placed on the page? should we support images and other data types?

comment:2 Changed 12 years ago by walter

One problem with my current approach is that these fields are not used in the journal search... will need to make an intervention in journaltoolbox.py as well.

comment:3 Changed 12 years ago by godiard

  • Cc godiard added

comment:4 Changed 12 years ago by walter

I was mistaken about my last comment: Search does find these fields.

comment:5 Changed 12 years ago by walter

Here is the design of the latest version (includes a proposed fix to #3207 as well)

http://wiki.sugarlabs.org/go/File:TAtags.png

comment:6 Changed 11 years ago by dnarvaez

  • Component changed from journal to sugar

comment:7 Changed 10 years ago by walter

  • Summary changed from Journal should support display of activity-specific metadata to Journal should support display of activity-specific badges

We can use tags already, but it would be nice if activities could add badges to the Journal.

comment:8 Changed 10 years ago by walter

We could add the badges to the comments section, which already supports adding an icon and some text. So the only real challenge is to make sure that the activity-specific badge icons are known to the Journal. Seems that copying them to:

~/.icons/sugar/scalable/emblems/

Note: See TracTickets for help on using tickets.