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