Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jul 06, 2009 at 12:51:43PM -0700, Edward Cherlin wrote: > On Fri, Jul 3, 2009 at 7:36 PM, Eben Eliason wrote: > > On Fri, Jul 3, 2009 at 2:17 PM, Gary C Martin wrote: > >> On 3 Jul 2009, at 10:01, Martin Langhoff wrote: > > >>> Wishlist: "show files by size" filter or option? If the Uruguay > >>> experience is any indicator, a fact of life is that users after all > >>> *will* hit: > > > > Yes, exposing size in the main list might be worth considering. > > I'm looking at the UI in Calibre, a Free Software personal document > database (home page calibre.kovidgoyal.net) that scans designated > folders, reads metadata from the files or from a server, and provides > a variety of views and sort options. It currently has an index of more > than 2,000 files on my hard drive. (I have a separate program for > cataloging my music files and maintaining playlists.) > > I can enter text in a search bar, and get back any document that has > that text in any field. Columns are > > o Title > o Author > o Size > o Date > o Rating > o Publisher > o Tags > o Series (Think course) > > Calibre also provides individual and bulk conversion of e-book formats. > > Journal could use all of those and more. Collaborators (total number, > or by name), something like a mime-type/Open With... menu, version > history, bookmarks. Since idea of having extra columns(and horizontal scrollbars) is not popular among design team ;) I guess the right way is having several UI profiles in Journal i.e. journal profile(by default), Calibre-like profile(for books), Rhytmbox-like(for audio) etc. The idea is that all these profiles are all about browsing objects(tagging, search etc) and keep these functionality in one place could be a good idea. Moreover there are some technical purposes for that: * caching images like(icons) in one process * accessing to objects metadata from one process * after adopting rainbow, the process of arbitrary access to all objects will be restricted and having arbitrary access only in one process could simplify situation -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 3, 2009 at 7:36 PM, Eben Eliason wrote:
> On Fri, Jul 3, 2009 at 2:17 PM, Gary C Martin wrote:
>> On 3 Jul 2009, at 10:01, Martin Langhoff wrote:
>>> Wishlist: "show files by size" filter or option? If the Uruguay
>>> experience is any indicator, a fact of life is that users after all
>>> *will* hit:
>
> Yes, exposing size in the main list might be worth considering.
I'm looking at the UI in Calibre, a Free Software personal document
database (home page calibre.kovidgoyal.net) that scans designated
folders, reads metadata from the files or from a server, and provides
a variety of views and sort options. It currently has an index of more
than 2,000 files on my hard drive. (I have a separate program for
cataloging my music files and maintaining playlists.)
I can enter text in a search bar, and get back any document that has
that text in any field. Columns are
o Title
o Author
o Size
o Date
o Rating
o Publisher
o Tags
o Series (Think course)
Calibre also provides individual and bulk conversion of e-book formats.
Journal could use all of those and more. Collaborators (total number,
or by name), something like a mime-type/Open With... menu, version
history, bookmarks.
>> Good point! Though arbitrary Journal sorting likely breaks many design
>> goals***,
I have heard otherwise for more than two years.
>> otherwise you'd have thought we would have the most basic of
>> features, sort by creation date, by now ;-)
Particularly if you were not aware of our painful shortage of
developers and the great long list of Things That Must Be Done First.
I'm impressed that we are as far along as we are overall, though
disappointed not to have a more useful Journal.
>> At the very least size taken by
>> an entry should be visible on the details view. Right now there is zero
>> indication other than just watching your total Journal grow in size via its
>> frame icon.
Title is what I miss most, but I would use most of the others
regularly and all at least on occasion.
>> ***Eben can you clarify this one? If locking folks into a 'view Journal only
>> by modification date' was an intentional design choice?
>
> Not at all. The proposed designs include a sort bar, which would
> function in the traditional fashion, but be sorted by date ("when") by
> default. See http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#03
>
> Tomeu has been working on using the standard GTK TreeView, so I think
> we're on track to add sorting by name, date, and participants (we need
> to decide what sorting by participants means...I think sorting by
> number of participants might be the useful choice, so that it's easy
> to surface the collaborative activities).
In a tree view, it would be useful to have an expandable list of
collaborators, sorted by name.
That and other sorted lists should be in correct language-specific
sorts in a suitable normalization, not a sort on raw Unicode code
points. For example, each language that uses accented Latin letters
has different rules for sorting them, and similarly for case and other
issues. ICU can deal with many of these complications. There is more
information at
http://userguide.icu-project.org/collation
http://userguide.icu-project.org/collation/faq
> If we expose file size in
> this list somehow, that would also be sortable.
>
> Eben
>
>> Regards,
>> --Gary
>>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
--
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://earthtreasury.org/worknet (Edward Mokurai Cherlin)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jul 6, 2009 at 7:15 AM, Gaurav Bhushan wrote: > Sure Fred, let me know what would be required of me. > Perhaps you could look at the list of nouns and verbs below and think of icons to represent them. If you see 'garycmartin' on irc://irc.freenode.net#sugar, ask him his views on what is most lacking. Some in the list (like Paint, Chat, Books) seem to have Sugar icons already, but perhaps Gary is thinking of a more generic expression. http://wiki.sugarlabs.org/go/Design_Team/Human_Interface_Guidelines/The_Sugar_Interface/Iconsis the wiki page Eben wrote for icons. Perhaps a gallery for review could be started here: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Toolbars/Icons I don't remember where Eben has saved the Sugar Theme Icons. Perhaps he could add a reference. Thanks for your contributions! --Fred > > Regards, > Gaurav > > On Mon, Jul 6, 2009 at 8:38 AM, Frederick Grose wrote: > >> On Sun, Jul 5, 2009 at 8:33 PM, Gary C Martin wrote: >> >>> ... One thing we could do >>> to try to move forward on the new toolbar concept is to build svg >>> icons for as many of the tabs that are already in use. We need to come >>> up with clear and identifiable icon for each **before** moving forward >>> (not just the few obvious common cases view/edit/image/text/format/ >>> colour/etc). >>> >>> Here's a quick trawl, not a full list. If we can't manage these, it >>> would be unfair to expect Activity Authors to have any more success. >>> Note: that some of these may need Activity specific variants, though >>> we may be able to drop some if we are willing to redesign some >>> Activities current UI: >>> >>> Algebra >>> Audio >>> Books >>> Boolean >>> Browse >>> Chat >>> Collaboration >>> Comment >>> Create >>> Edit >>> Effects >>> Face >>> Format >>> Game >>> Graph >>> Help >>> Image >>> Learn >>> Lessons >>> Library >>> Miscellaneous >>> Montage >>> Video >>> Paint >>> Photo >>> Plain >>> Play >>> Project >>> Read >>> Robot >>> Save/Load >>> Shapes >>> Slides >>> Sort >>> Tab >>> Table >>> Text >>> Tools >>> Trigonometry >>> View >>> Voice >>> Watch >> >> >> Perhaps Gaurav Bhushan could help with icons. He seems to have a knack >> for expressing abstractions in icons, see >> http://wiki.sugarlabs.org/go/File:Social_Communication_System.png. >> >> --Fred >> > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
Hi Eben, On 5 Jul 2009, at 23:52, Gary C Martin wrote: > On 4 Jul 2009, at 04:19, Eben Eliason wrote: >> I'll throw this idea back out there for fun, too. I don't know if >> there's a way to do even this without adding too much complexity, but >> we did make some mockups of an "advanced" sort bar, which instead of >> sorting on columns allowed creation of hierarchical sorting by >> metadata. For example, I could use the "what" filter to select >> "audio" >> files, and then use the sort bar to say: "sort by artist, then by >> album, then by track". Any Journal entries which had metadata keys >> for >> "artist", "album", and "track" would then appear sorted accordingly, >> and the section dividers would show the values for the various keys >> so >> that the hierarchy was logically browsable. >> >> It's a powerful idea, but so far we just haven't thought it to be >> worth the added complexity. Keeping the Journal as simple to use as >> possible is paramount. > > I'll maybe try have a go at a simple mock-up. Could either be part of > a row titling the current columns, as in a subtle little arrow button > with several sort by options in it – "sort by modified", "sort by > created", "sort by size". Or perhaps as a regular button & palette in > the toolbar (though toolbar is filling up fast with icons and is > likely too 'featureitus' scary already in my mock-ups). I rather like this approach to exposing row sorting, if you don't mind that my mock-ups have grid and list as the primary views (rather than your action-view, object-view): http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Extended_list_view_palette The list view palette is extended to cover sorting feature requirements. View by last edit (modification date), is the current presentation of the Journal. View by creation date, would list objects creation date (do we store this?); when in this mode rather than "16 min ago", the time column would display the real creation date "Today 12:30pm", "July 5th", "November 10th 2008". View by storage size, would sort by storage space taken up so that large files could be removed if short on space, the column usually used for showing time would instead show Kb/Mb type information (no extra columns need, and helps show what sort context a list view is in.) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jul 6, 2009 at 13:56, Sascha Silbe wrote: > On Mon, Jul 06, 2009 at 11:08:21AM +0200, Tomeu Vizoso wrote: > >>> You're right on spot. The only prefixes used (but not defined for the >>> query) >>> are: >> >> Not quite, the association from mime_type: to M is doing when >> constructing the query: [...] >> So to support that we just need to call add_prefix on the QueryParser >> for every field prefix. > > Which is exactly what I meant: we don't call add_prefix() currently, so we > don't define prefixes for the query. Got it. I thought you were saying it was more complex than that so couldn't be done for 0.86. Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKUeaAAAoJELpz82VMF3DavuUH/jNQ/aEXWyTXM0cn9mJNsDM3 > Ge7DylaRKjq0/BzEAE65Yes//nSZW8HSSAjdcKnwg4LhRA8MEGAkqIG/eEwiltEV > Z80cjgbgws6z+H+ZSE8TgrKam139CryY6foCgglgbkU4qyA6FTrwKmFdbDwPPd44 > Ad9kz9Fd246Xh/dYmToRcYMqCCUScklCOmoX7hU/x5WPDvTrEYuMcmvAYiqThEmg > 5hC85LQL8ybl8xxpqh1dXawlT1Zsw7JBLxq90KTITqX2uBVeO67DeNKVsu9xuHT0 > hS8Cd111bK73nnToMknv1b/py51HmhUHjiWDMggUbAZrwwcfBX+W5syZX0NPGD0= > =eFVO > -END PGP SIGNATURE- > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jul 06, 2009 at 11:08:21AM +0200, Tomeu Vizoso wrote: You're right on spot. The only prefixes used (but not defined for the query) are: Not quite, the association from mime_type: to M is doing when constructing the query: [...] So to support that we just need to call add_prefix on the QueryParser for every field prefix. Which is exactly what I meant: we don't call add_prefix() currently, so we don't define prefixes for the query. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jul 6, 2009 at 10:51, Sascha Silbe wrote: > On Sat, Jul 04, 2009 at 04:55:57PM +0100, Gary C Martin wrote: > >> Just to confirm; I take it that Xapians prefix maps haven't been used so >> far in the Journal index implementation (i.e. title:Paint, >> description:meeting, or tags:homework)? Point me at rep Sugar source if >> that's quicker (not sure where to look to check this). > > You're right on spot. The only prefixes used (but not defined for the query) > are: > > _PREFIX_UID = 'Q' > _PREFIX_ACTIVITY = 'A' > _PREFIX_ACTIVITY_ID = 'I' > _PREFIX_MIME_TYPE = 'M' > _PREFIX_KEEP = 'K' > > I.e. to search for all documents of type text/plain you can use the query > string "Mtext/plain", but not "mime_type:text/plain". Not quite, the association from mime_type: to M is doing when constructing the query: http://xapian.org/docs/apidoc/html/classXapian_1_1QueryParser.html#dfd545b4ac739adc2e4171169a500f33 And, from the docs, it does more than just appending M to the query string, as it can do things like author:"charles dickens" and title:(mice men). So to support that we just need to call add_prefix on the QueryParser for every field prefix. Regards, Tomeu > See [1]. > > I'd like to expose a better IR search facility in the future, but not within > 0.86 timeframe (there are several open, hard problems). > > > [1] > http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/blobs/master/src/carquinyol/indexstore.py > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKUbsrAAoJELpz82VMF3DaRTAH+QFWfnGvagCl5Vw3ujZceInp > v4D7PKANidrP8+8GShMaeeXbN1eS7xO4pxEmcQsHqCpEnziS9LM6XGHuuHv67Ab9 > BNg+2FMSZbwnBvhK0ZHBclOKxzQZt20uNJywAb5DU4AkyqqGbAR6+KCrKWb4rpH9 > EjvZEQqTGVVrrj4HNMmHU7C7co++ftAlrTLK3jQs1qw0HHvxBZZgU5Y4SBjqPtM2 > v7c/Nb+NfP4wD5TZAonb9d4eCMf0dqWkgprWTzJ0/q0qLF8hh2bhHMbdF2jZC+YE > +cPPg6NLSiPcFkuHbTLkI5nuOervWpgV9anf6Wh/bXy33nMEjciHf2JtOL4AMcA= > =DwBt > -END PGP SIGNATURE- > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sat, Jul 04, 2009 at 04:55:57PM +0100, Gary C Martin wrote: Just to confirm; I take it that Xapians prefix maps haven't been used so far in the Journal index implementation (i.e. title:Paint, description:meeting, or tags:homework)? Point me at rep Sugar source if that's quicker (not sure where to look to check this). You're right on spot. The only prefixes used (but not defined for the query) are: _PREFIX_UID = 'Q' _PREFIX_ACTIVITY = 'A' _PREFIX_ACTIVITY_ID = 'I' _PREFIX_MIME_TYPE = 'M' _PREFIX_KEEP = 'K' I.e. to search for all documents of type text/plain you can use the query string "Mtext/plain", but not "mime_type:text/plain". See [1]. I'd like to expose a better IR search facility in the future, but not within 0.86 timeframe (there are several open, hard problems). [1] http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/blobs/master/src/carquinyol/indexstore.py CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sat, Jul 4, 2009 at 17:55, Gary C Martin wrote: > On 4 Jul 2009, at 09:56, Tomeu Vizoso wrote: > >> On Sat, Jul 4, 2009 at 05:19, Eben Eliason wrote: >>> >>> It sounds like you're describing a NOT filter (eg. kind:text NOT >>> activity:terminal), though, which the current UI doesn't support, as >>> all of the filter options are combined with an AND. I think adding >>> boolean AND/OR/NOT controls to the filter UI would definitely >>> complicate things too much, but we could again support these kinds of >>> queries within the search field. >> >> Btw, we currently support this query format: >> http://xapian.org/docs/queryparser.html > > Hey cool thanks for the link – I didn't realise how much was silently > supported! The most I had been using was the occasional phrase search with > double quotes. > > Just to confirm; I take it that Xapians prefix maps haven't been used so far > in the Journal index implementation (i.e. title:Paint, description:meeting, > or tags:homework)? Point me at rep Sugar source if that's quicker (not sure > where to look to check this). That's not implemented as of yet, though I don't see any hurdle right now. What I should warn about is that the more information we give to xapian, the more sophisticated stuff it can do; but it will have a cost in disk space usage and may slow some operations. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sun, Jul 5, 2009 at 8:33 PM, Gary C Martin wrote: > ... One thing we could do > to try to move forward on the new toolbar concept is to build svg > icons for as many of the tabs that are already in use. We need to come > up with clear and identifiable icon for each **before** moving forward > (not just the few obvious common cases view/edit/image/text/format/ > colour/etc). > > Here's a quick trawl, not a full list. If we can't manage these, it > would be unfair to expect Activity Authors to have any more success. > Note: that some of these may need Activity specific variants, though > we may be able to drop some if we are willing to redesign some > Activities current UI: > > Algebra > Audio > Books > Boolean > Browse > Chat > Collaboration > Comment > Create > Edit > Effects > Face > Format > Game > Graph > Help > Image > Learn > Lessons > Library > Miscellaneous > Montage > Video > Paint > Photo > Plain > Play > Project > Read > Robot > Save/Load > Shapes > Slides > Sort > Tab > Table > Text > Tools > Trigonometry > View > Voice > Watch Perhaps Gaurav Bhushan could help with icons. He seems to have a knack for expressing abstractions in icons, see http://wiki.sugarlabs.org/go/File:Social_Communication_System.png. --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 4 Jul 2009, at 03:36, Eben Eliason wrote: > That said, I'm actually thinking that the tag > dropdown should be an extension of the search field itself. Perhaps > it's just to the right, and only needs to be a little down arrow that > reveals the tags (or perhaps we even modify the search entry to have > this button). Yes, if the toolbar tag button is deemed another scary button too many, and we still want the functionality, it could be placed in the search field magnifying-glass with minimum impact for a novice user (they just wouldn't find it until shown, or curious). See the Safari browser search field for reference. Apple use a magnifying-glass with a very small disclosure triangle that reveals the search history, we could have the same in Journal reveal a sorted tag list/cloud. > Previous mockups I'd worked on were based on the idea > that a tag suggestion window would popup beneath the search field > while typing to show possible tags. I guess you could have the same sorted tag list/cloud palette appear for either a click of the magnifying-glass, or when typing, as you typed you'd get the auto-complete suggestion, and the tag list would visually filter the matches shown. That would really be quite some serious coding effort though! > The thought for the explicit > dropdown arrow would be to choose tags without having to start typing. Yes, browsing/navigation of existing tags without typing will go a long way to getting folks to actually use them, especially out target demographic. Though this feature can initially be left off and, added at a later date. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
Hi James, On 3 Jul 2009, at 19:29, James Zaki wrote: > Perhaps this is a late reply, (I am yet to read the last 6 or so > digests of to 20+ that were in my inbox) No not late at all! :-) > But I am always sensitive of little incremental additions that seem > like it would be useful. > > I always try to think about the first time I used sugar. In > particular, what helped by being very simple. We see sugar evolving, > and perhaps forget what it was like that first time. Perhaps we > should harass some friends and families' kids who've not seen it, > and get their feedback. +1 > If a child new to the sugar interface (XO or otherwise) feels > bombarded with options, it could make things harder. +1 > In particular to the pictures, there are lots of activities in that > dropdown. Has that always been so big? To me that would be > intimidating for the first user experience. Just to check you're referring to: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#What.2FAnything_palette Yes this mock-up is currently showing the 33 Activities as shipped in the Sugar on a Stick Strawberry release from week or two ago. There's lots of discussion about what Activities a distribution should ship pre-installed, but this is something a school deployment, or parents group would want to be involved in. If I was introducing this to a child for the first time, I'd only install a small number of Activities to let them get comfortable. FWIW: I think the original G1G1 image installs about 27 Activities. With the currently shipping Journal, there is a text menu called "Anything", when you click on it, it drops down a single vertical column list of everything you see in the above mock-up. The list is much larger than the height of screen, so you only see the first 14 or so items. To see the others, you have to scroll the menu using a small arrow at the bottom of the screen. When you want to undo your filter, you have to open the menu again and scroll it all the way back up again to find the "Anything" entry to click on. It's quite a fuss once you have many more than 9 Activities installed (the menu also holds 5 generic file type filters for text/image/audio/video/link). The multi-column approach is an attempt to reduce the need to scroll through tall menus. If the Uruguay deployment has shown us anything, it's that kids love installing lots and lots of Activities :-) At http://activities.sugarlabs.org/ there is already over 150 available for them! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 1 Jul 2009, at 11:36, Tomeu Vizoso wrote: > On Tue, Jun 30, 2009 at 19:02, Gary C Martin > wrote: >> Being Mr ActivityTeam at the moment, I do really worry about the >> amount of work this is going to be to get Activities updated and >> complying to a large toolbar redesign. Supporting both toolbar API >> styles will help, but I think we'll end up with multiple toolbar >> styles in different Activities for perhaps 6 months to a year or >> more. >> That's a bad backward step for usability. Just look at the amount of >> time/effort it is taking to migrate Activities over to SL >> infrastructure, let alone making anything but minor maintenance code >> changes to them. > > True, so what do you suggest here? No magic answers I'm afraid. I'm just saying... One thing we could do to try to move forward on the new toolbar concept is to build svg icons for as many of the tabs that are already in use. We need to come up with clear and identifiable icon for each **before** moving forward (not just the few obvious common cases view/edit/image/text/format/ colour/etc). Here's a quick trawl, not a full list. If we can't manage these, it would be unfair to expect Activity Authors to have any more success. Note: that some of these may need Activity specific variants, though we may be able to drop some if we are willing to redesign some Activities current UI: Algebra Audio Books Boolean Browse Chat Collaboration Comment Create Edit Effects Face Format Game Graph Help Image Learn Lessons Library Miscellaneous Montage Video Paint Photo Plain Play Project Read Robot Save/Load Shapes Slides Sort Tab Table Text Tools Trigonometry View Voice Watch I'm thinking the toolbar design as specced does not seem viable for the 0.86 time scale. Leaving us with the nasty issue trying to solve what I see as a current worst toolbar usability offender, "Stop button must be visible at all times." Perhaps a stop gap measure of placing the Activity stop button permanently in the sacrosanct top right corner? Can't believe I suggest that, but it's the best suggestion I have... Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 4 Jul 2009, at 04:19, Eben Eliason wrote: > I'll throw this idea back out there for fun, too. I don't know if > there's a way to do even this without adding too much complexity, but > we did make some mockups of an "advanced" sort bar, which instead of > sorting on columns allowed creation of hierarchical sorting by > metadata. For example, I could use the "what" filter to select "audio" > files, and then use the sort bar to say: "sort by artist, then by > album, then by track". Any Journal entries which had metadata keys for > "artist", "album", and "track" would then appear sorted accordingly, > and the section dividers would show the values for the various keys so > that the hierarchy was logically browsable. > > It's a powerful idea, but so far we just haven't thought it to be > worth the added complexity. Keeping the Journal as simple to use as > possible is paramount. I'll maybe try have a go at a simple mock-up. Could either be part of a row titling the current columns, as in a subtle little arrow button with several sort by options in it – "sort by modified", "sort by created", "sort by size". Or perhaps as a regular button & palette in the toolbar (though toolbar is filling up fast with icons and is likely too 'featureitus' scary already in my mock-ups). > Something I would like to explore, > though, is exposing metadata within the detail pages of Journal > entries. It would be neat, for instance, if photos taken in record > actually had a "photographer: " label in the details, to > make the detail view more useful and to enhance the detail view for > specific kinds of objects. I have some neat mockups showing a possible > UI for this. I'll try to dig them up. +1, the details page is out of the way and could do with some more actual details (entry file size being the currently most useful I've seen go by so far). > Perhaps we could somehow represent "type" by showing a stack of the > generic type > documents. Maybe it would have the "data" icon on the front page, but > visually have a few documents in the stack. I'll play with it. Fab, thanks. > These are still separate in the current mockups, right? Yes. > There's basically an icon for each "key", where the possible keys > are "who", > "what", and "when", plus the generic search field. It's nice that all > of these filtering options are lined up at the top, and that it's > possible to add to the filter to narrow down on the search results by > adjusting more of the filters. Yep (though I'd like a quick way to clear a search rather than the current trawl through each filter). > PS. Gary, the mockups are looking good so far. I'll give some thought > to the icons, and try to dig up some of my past designs for bits and > pieces of this. Thanks. Having a bit of trouble with the when/anytime palette. If we want each toolbar icon to visually represent the filter, it means we need a series of icons for today, since yesterday, past week, past month, past year (have a few misc. icon ideas but not a sensible set to cover all). http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#When.2FAnytime_palette FWIW: There's also another shot at a possible tag cloud treatment: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Show_frequency_as_proportional_size Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 4 Jul 2009, at 16:29, Gary C Martin wrote: > > P.S. Should have another round of updates to the mock-ups later today. OK, that's the next revision & update of mock-up images with comments – still more to add (When/Who), but the toolbars at least show icons for the main potential top-level filters (Favourite/What/When/Who/Tags). http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes Some example Tag palette treatments up, worth a quick look/feedback if you have time. Regards, --Gary P.S. Will likely leave it a day or so before next round. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 4 Jul 2009, at 09:56, Tomeu Vizoso wrote: > On Sat, Jul 4, 2009 at 05:19, Eben Eliason wrote: >> >> It sounds like you're describing a NOT filter (eg. kind:text NOT >> activity:terminal), though, which the current UI doesn't support, as >> all of the filter options are combined with an AND. I think adding >> boolean AND/OR/NOT controls to the filter UI would definitely >> complicate things too much, but we could again support these kinds of >> queries within the search field. > > Btw, we currently support this query format: > http://xapian.org/docs/queryparser.html Hey cool thanks for the link – I didn't realise how much was silently supported! The most I had been using was the occasional phrase search with double quotes. Just to confirm; I take it that Xapians prefix maps haven't been used so far in the Journal index implementation (i.e. title:Paint, description:meeting, or tags:homework)? Point me at rep Sugar source if that's quicker (not sure where to look to check this). --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 4 Jul 2009, at 10:08, Tomeu Vizoso wrote: > On Fri, Jul 3, 2009 at 20:29, James Zaki wrote: >> Perhaps this is a late reply, (I am yet to read the last 6 or so >> digests of >> to 20+ that were in my inbox) >> But I am always sensitive of little incremental additions that seem >> like it >> would be useful. > > Totally agreed. We had to start with something before Sugar was in the > hands of children, but now that it's widely used, we should avoid > changing whole parts of it without user feedback. > >> I always try to think about the first time I used sugar. In >> particular, what >> helped by being very simple. We see sugar evolving, and perhaps >> forget what >> it was like that first time. Perhaps we should harass some friends >> and >> families' kids who've not seen it, and get their feedback. > > SoaS is making very easy to start pilots anywhere, so I trust > developers are going to have very good feedback in a short time. Simon > is already using SoaS with kids in Berlin, for example. > >> If a child new to the sugar interface (XO or otherwise) feels >> bombarded with >> options, it could make things harder. >> Just my two cents I always voice on this. > > Yeah, we have had already feedback about the benefits of Sugar's > "clarity". We shouldn't let those people down by indulging ourselves > in featuritis. > > By this I don't mean that we should limit ourselves in improving > Sugar, we know that there's a ton of stuff to improve and new features > to implement, but if we try hard we are going to find ways to add > those features without cluttering the UI. > > I'm very happy to read these recent threads because we are making > enormous progress in devising how to expose powerful new features > without raising the bar for new users. +1 for what Tomeu said :-) I see the mock-up work currently under way as a technique to get closer, visually, to such issues before too much developer energy is spent on them. Whatever items are realistic, agreed, and then implemented, will still need user testing – in the hands of some of our target users – and likely reworked some more. The expectation is not to get the perfect design (there never will be such a thing), but to be better than the previous design/ implementation by an amount worth the cost to get there (understanding better will be a bit fuzzy to define). Regards --Gary P.S. Should have another round of updates to the mock-ups later today. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 3, 2009 at 20:29, James Zaki wrote: > Perhaps this is a late reply, (I am yet to read the last 6 or so digests of > to 20+ that were in my inbox) > But I am always sensitive of little incremental additions that seem like it > would be useful. Totally agreed. We had to start with something before Sugar was in the hands of children, but now that it's widely used, we should avoid changing whole parts of it without user feedback. > I always try to think about the first time I used sugar. In particular, what > helped by being very simple. We see sugar evolving, and perhaps forget what > it was like that first time. Perhaps we should harass some friends and > families' kids who've not seen it, and get their feedback. SoaS is making very easy to start pilots anywhere, so I trust developers are going to have very good feedback in a short time. Simon is already using SoaS with kids in Berlin, for example. > If a child new to the sugar interface (XO or otherwise) feels bombarded with > options, it could make things harder. > Just my two cents I always voice on this. Yeah, we have had already feedback about the benefits of Sugar's "clarity". We shouldn't let those people down by indulging ourselves in featuritis. By this I don't mean that we should limit ourselves in improving Sugar, we know that there's a ton of stuff to improve and new features to implement, but if we try hard we are going to find ways to add those features without cluttering the UI. I'm very happy to read these recent threads because we are making enormous progress in devising how to expose powerful new features without raising the bar for new users. Thanks! Tomeu > In particular to the pictures, apart from the two identical cloud icons, > there are lots of activities in that dropdown. Has that always been so big? > To me that would be intimidating for the first user experience. > > James. > > >> >> Date: Fri, 3 Jul 2009 04:25:54 +0000 >> From: Aleksey Lim >> Subject: Re: [Sugar-devel] Journal feature request--more data in main >> display >> To: Gary C Martin >> Cc: Sugar Devel >> Message-ID: <20090703042553.ga15...@antilopa-gnu> >> Content-Type: text/plain; charset=us-ascii >> >> On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote: >> > On 2 Jul 2009, at 02:40, Gary C Martin wrote: >> > >> >> On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote: >> >>> On Mon, Jun 29, 2009 at 18:14, Gary C Martin >> >>> wrote: >> >>>> - Better Anything toolbar filter palette (use a grid layout to >> >>>> minimise >> >>>> scrolling) >> >>> >> >>> Yeah, that will be great. I think Walter already submitted a patch to >> >>> move the file types up. >> >> >> >> Yea, saw the patch from Walter, that alone should help even if we >> >> stall on doing more. >> >> >> >> I have a mock-up I was experimenting with grid layouts, still >> >> tinkering, and I can't think of a good 'filter' icon for the >> >> replacement button (a common one seems to be a funnel shape) :-) >> >> >> >> The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone', >> >> and my below 'Tag' filters can all become toolbar icons (not text). >> >> This saves a heap of toolbar space, and allows room for a couple more >> >> buttons on the far right for 'Grid' and current 'List' view. >> > >> > Aleksey was keen to see any Journal mock-up work in progress I had, >> > early as possible, so here's where I'm at :-) There's plenty to do >> > still, images are intended to help bounce ideas about, poke at the grey >> > matter between our ears, and get a feel for how things could (or not) be >> > done: >> > >> > >> > http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes >> >> Some thoughts: >> >> * what about adding ultra compact list view for objects(not actions) >> like list view in Library[1] >> the purpose is, if user has lots of objects it could be useful idea to >> show as much as possible objects on one screen >> >> * having several column/grid layouts >> for example its very useful for books to have columns for author, >> genre, date; so, user can see the whole valuable info at once and sort >> objects by these columns; and so separate layouts for video audio >> etc. files >> >> * additional types
Re: [Sugar-devel] Journal feature request--more data in main display
On Sat, Jul 4, 2009 at 05:19, Eben Eliason wrote: > > It sounds like you're describing a NOT filter (eg. kind:text NOT > activity:terminal), though, which the current UI doesn't support, as > all of the filter options are combined with an AND. I think adding > boolean AND/OR/NOT controls to the filter UI would definitely > complicate things too much, but we could again support these kinds of > queries within the search field. Btw, we currently support this query format: http://xapian.org/docs/queryparser.html Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 3, 2009 at 1:57 PM, Aleksey Lim wrote: > On Fri, Jul 03, 2009 at 06:13:24PM +0100, Gary C Martin wrote: >> Hi Aleksey, >> >> On 3 Jul 2009, at 05:25, Aleksey Lim wrote: >>> On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote: Aleksey was keen to see any Journal mock-up work in progress I had, early as possible, so here's where I'm at :-) There's plenty to do still, images are intended to help bounce ideas about, poke at the grey matter between our ears, and get a feel for how things could (or not) be done: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes >>> >>> Some thoughts: >>> >>> * what about adding ultra compact list view for objects(not actions) >>> like list view in Library[1] >>> the purpose is, if user has lots of objects it could be useful idea >>> to >>> show as much as possible objects on one screen I prefer to keep the activity icons always at a constant size. We played around with smaller lists for the reason you suggest, but we didn't feel that the resulting designs were suitable for kids, both because the fonts and icons were smaller and harder to read, and because the clickable targets were so much smaller. >> We do want to show plenty of entries, but need to keep in mind visible >> size of each text/icon row entry. My current call is to make each >> Journal entry row 'richer' rather than trying to cram on more rows >> (encourage folks to search/filter down to a small number of results). I think this is the right approach. > Maybe having several views/layouts(for several purposes) is more useful > idea then only one common view for all purposes? I mean: > > * compact view > could be not trivial(horizontal scrolls) but highly > configured(show/hide columns) > for people who want narrow lines with additional columns > (to sort them for example) > * grid view > and use filters to show what user needs(because there could a lack > of useful info in this view) >> The grid view is better for looking and scrubbing through many entries. >> In Library you've made your rows richer by adding many more options for >> showing extra columns of information (author, artist, date, album, disk, >> track, genre, copyright, ...) at the cost of lots of horizontal >> scrolling, and option complexity. >> >>> * having several column/grid layouts >>> for example its very useful for books to have columns for author, >>> genre, date; so, user can see the whole valuable info at once and >>> sort >>> objects by these columns; and so separate layouts for video audio >>> etc. files I think it's far better to have custom activities for these types of use cases. I think the Journal should be a really powerful tool for locating this kind of information, but adding lots of complicated views for various formats which kids may or may not even have lots of could easily add needless complexity. I think we should focus on making the best all-purpose solution. I'll throw this idea back out there for fun, too. I don't know if there's a way to do even this without adding too much complexity, but we did make some mockups of an "advanced" sort bar, which instead of sorting on columns allowed creation of hierarchical sorting by metadata. For example, I could use the "what" filter to select "audio" files, and then use the sort bar to say: "sort by artist, then by album, then by track". Any Journal entries which had metadata keys for "artist", "album", and "track" would then appear sorted accordingly, and the section dividers would show the values for the various keys so that the hierarchy was logically browsable. It's a powerful idea, but so far we just haven't thought it to be worth the added complexity. Keeping the Journal as simple to use as possible is paramount. >> The option complexity is too high for me, and causes horizontal >> scrolling (mentioned above), though the ability to sort on any arbitrary I think we should avoid horizontal scrolling at all costs. Not only is it a nuisance, but I like the logical mapping the scrolling axis to time (or, I suppose, to whatever sort is selected). >> column is a bonus. Personally I think all the extra column information >> would be much better treated as tags, that way you can use the existing >> Journal tagging mechinisum, search and drill down to the entries you are >> after, and with the title + tag row entry still get to directly browse >> that information if needed. Yup. I think we can make the search and tagging even more powerful by supporting user created metadata as well. This is obviously an advanced feature, but that's OK with me since it doesn't get in the way of basic use. Typing in key:value pairs into the tag field should provide searchable keys. In this manner, it should be possible to do searches for "color:red" to match only on entries which have the value "red" for the key "color", instead of all entries which had the tag "red",
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 3, 2009 at 2:17 PM, Gary C Martin wrote:
> On 3 Jul 2009, at 10:01, Martin Langhoff wrote:
>
>> On Fri, Jul 3, 2009 at 5:29 AM, Gary C Martin wrote:
>>>
>>> Aleksey was keen to see any Journal mock-up work in progress I had,
>>> early as possible, so here's where I'm at :-) There's plenty to do
>>> still, images are intended to help bounce ideas about, poke at the
>>> grey matter between our ears, and get a feel for how things could (or
>>> not) be done:
>>>
>>>
>>> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes
>>
>> Very cool. I do agree the filter is very culture-dependent.
>>
>> On a similar vein, the 'tag' icon has no visual association with the
>> many tags on screen. If they had a similar shape, then it'd be easy to
>> connect, for users who don't recognise a "tag" and the (somewhat odd)
>> use of "tag" to mean "a bit of metadata on a digital resource".
>
> I just 'acquired' the tag/label icon from Eben's mock-ups. Assume he had
> though about this way more than me :-) Sure there are plenty of revisions,
> reworks, and cherry picking.
Heh, you did. Nice. Did those mockups show how we might show the tags
themselves in the UI, though? I do think it's important to make the
label reflect the UI. That said, I'm actually thinking that the tag
dropdown should be an extension of the search field itself. Perhaps
it's just to the right, and only needs to be a little down arrow that
reveals the tags (or perhaps we even modify the search entry to have
this button). Previous mockups I'd worked on were based on the idea
that a tag suggestion window would popup beneath the search field
while typing to show possible tags. The thought for the explicit
dropdown arrow would be to choose tags without having to start typing.
>> Wishlist: "show files by size" filter or option? If the Uruguay
>> experience is any indicator, a fact of life is that users after all
>> *will* hit:
Yes, exposing size in the main list might be worth considering.
>> - problems with fitting files (large and small) in USB disks
>>
>> - problems with their Journal taking too much space
>>
>> - problems with installed Activities taking too much disk space
>
> Good point! Though arbitrary Journal sorting likely breaks many design
> goals***, otherwise you'd have thought we would have the most basic of
> features, sort by creation date, by now ;-) At the very least size taken by
> an entry should be visible on the details view. Right now there is zero
> indication other than just watching your total Journal grow in size via it's
> frame icon.
>
> ***Eben can you clarify this one? If locking folks into a 'view Journal only
> by modification date' was an intentional design choice?
Not at all. The proposed designs include a sort bar, which would
function in the traditional fashion, but be sorted by date ("when") by
default. See http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#03
Tomeu has been working on using the standard GTK TreeView, so I think
we're on track to add sorting by name, date, and participants (we need
to decide what sorting by participants means...I think sorting by
number of participants might be the useful choice, so that it's easy
to surface the collaborative activities). If we expose file size in
this list somehow, that would also be sortable.
Eben
> Regards,
> --Gary
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 06:29:21PM +0100, Gary C Martin wrote: > On 3 Jul 2009, at 05:53, Aleksey Lim wrote: > >> On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: >>> * additional types of filters >>> for example Library has[2] several types to filter objects >>> >>> * user tags >>> * object traits(additional columns from previous section) like >>> author, >>>genre, date for books >>> * activity creators(grouping by activity_id field) >>> * types of objects(like top section in filter palette)[3] >>> * filter by participants >>> * filter by sources(if we are in shared mode) >>> >>> I'm not sure that all of these modes are useful, but something could >>> be(or another types) >> >> like http://wiki.sugarlabs.org/go/File:-5.png > > The filters (currently in Journal, and in my mock-ups) are in separate > top level toolbar controls. I'm basically just switching them to icons > instead of text menus. From your mock-up, "User tags" would be > controlled via a palette (not yet finished the mock-up) from that tag/ > label icon shown in the toolbar. Next to it will also be added a buddy > icon (white outline) for a filter palette (not yet finished the mock-up) > that looks like it would cover "Participants". > > Where you have "Object types" I understand that as file mime types, > which was what I placed at the top of that palette before your mock-up > modification :-) > > Your "Object traits" I thing a best just dealt with in a universal way > as tags, no new ontology needed and gets to benefit from any general tag > improvements we make to Sugar (details entry, activity naming dialogue > improvements, auto completion, 'tags under title' Journal entry display, > the Object Chooser). > > I'm not convinced I understand your "Creators" category. Is this > original author, the Activity used to build the entry, or something > else? its just grouping my activity_id DS field > > Regards, > --Gary > -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 08:29:10PM +0200, James Zaki wrote: > Perhaps this is a late reply, (I am yet to read the last 6 or so digests of > to 20+ that were in my inbox) > But I am always sensitive of little incremental additions that seem like it > would be useful. > > I always try to think about the first time I used sugar. In particular, what > helped by being very simple. We see sugar evolving, and perhaps forget what > it was like that first time. Perhaps we should harass some friends and > families' kids who've not seen it, and get their feedback. Unfortunately we are limited in our resources, for example wadeb managed to produce only ONE(thats a shame!) new sugar user for past year. > If a child new to the sugar interface (XO or otherwise) feels bombarded with > options, it could make things harder. > Just my two cents I always voice on this. > > In particular to the pictures, apart from the two identical cloud icons, > there are lots of activities in that dropdown. Has that always been so big? > To me that would be intimidating for the first user experience. Thats a good point, thanks for this -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
Perhaps this is a late reply, (I am yet to read the last 6 or so digests of to 20+ that were in my inbox) But I am always sensitive of little incremental additions that seem like it would be useful. I always try to think about the first time I used sugar. In particular, what helped by being very simple. We see sugar evolving, and perhaps forget what it was like that first time. Perhaps we should harass some friends and families' kids who've not seen it, and get their feedback. If a child new to the sugar interface (XO or otherwise) feels bombarded with options, it could make things harder. Just my two cents I always voice on this. In particular to the pictures, apart from the two identical cloud icons, there are lots of activities in that dropdown. Has that always been so big? To me that would be intimidating for the first user experience. James. > Date: Fri, 3 Jul 2009 04:25:54 + > From: Aleksey Lim > Subject: Re: [Sugar-devel] Journal feature request--more data in main >display > To: Gary C Martin > Cc: Sugar Devel > Message-ID: <20090703042553.ga15...@antilopa-gnu> > Content-Type: text/plain; charset=us-ascii > > On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote: > > On 2 Jul 2009, at 02:40, Gary C Martin wrote: > > > >> On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote: > >>> On Mon, Jun 29, 2009 at 18:14, Gary C Martin > >>> wrote: > >>>> - Better Anything toolbar filter palette (use a grid layout to > >>>> minimise > >>>> scrolling) > >>> > >>> Yeah, that will be great. I think Walter already submitted a patch to > >>> move the file types up. > >> > >> Yea, saw the patch from Walter, that alone should help even if we > >> stall on doing more. > >> > >> I have a mock-up I was experimenting with grid layouts, still > >> tinkering, and I can't think of a good 'filter' icon for the > >> replacement button (a common one seems to be a funnel shape) :-) > >> > >> The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone', > >> and my below 'Tag' filters can all become toolbar icons (not text). > >> This saves a heap of toolbar space, and allows room for a couple more > >> buttons on the far right for 'Grid' and current 'List' view. > > > > Aleksey was keen to see any Journal mock-up work in progress I had, > > early as possible, so here's where I'm at :-) There's plenty to do > > still, images are intended to help bounce ideas about, poke at the grey > > matter between our ears, and get a feel for how things could (or not) be > > done: > > > > > http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes > > Some thoughts: > > * what about adding ultra compact list view for objects(not actions) > like list view in Library[1] > the purpose is, if user has lots of objects it could be useful idea to > show as much as possible objects on one screen > > * having several column/grid layouts >for example its very useful for books to have columns for author, >genre, date; so, user can see the whole valuable info at once and sort >objects by these columns; and so separate layouts for video audio >etc. files > > * additional types of filters > for example Library has[2] several types to filter objects > > * user tags > * object traits(additional columns from previous section) like author, >genre, date for books > * activity creators(grouping by activity_id field) > * types of objects(like top section in filter palette)[3] > * filter by participants > * filter by sources(if we are in shared mode) > > I'm not sure that all of these modes are useful, but something could > be(or another types) > > * several levels of chosen filters > dunno about others but for me its very useful > (see bottom panel on [4]) > for example I can filter all text/plane files and separate from them > only objects that were made by Terminal activity > > > [1] http://wiki.sugarlabs.org/go/File:-3.png > [2] http://wiki.sugarlabs.org/go/File:-1.png > [3] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#.232 > [4] http://wiki.sugarlabs.org/go/File:-4.png > > -- > Aleksey > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 3 Jul 2009, at 10:01, Martin Langhoff wrote: > On Fri, Jul 3, 2009 at 5:29 AM, Gary C Martin > wrote: >> Aleksey was keen to see any Journal mock-up work in progress I had, >> early as possible, so here's where I'm at :-) There's plenty to do >> still, images are intended to help bounce ideas about, poke at the >> grey matter between our ears, and get a feel for how things could (or >> not) be done: >> >> >> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes > > Very cool. I do agree the filter is very culture-dependent. > > On a similar vein, the 'tag' icon has no visual association with the > many tags on screen. If they had a similar shape, then it'd be easy to > connect, for users who don't recognise a "tag" and the (somewhat odd) > use of "tag" to mean "a bit of metadata on a digital resource". I just 'acquired' the tag/label icon from Eben's mock-ups. Assume he had though about this way more than me :-) Sure there are plenty of revisions, reworks, and cherry picking. > Wishlist: "show files by size" filter or option? If the Uruguay > experience is any indicator, a fact of life is that users after all > *will* hit: > > - problems with fitting files (large and small) in USB disks > > - problems with their Journal taking too much space > > - problems with installed Activities taking too much disk space Good point! Though arbitrary Journal sorting likely breaks many design goals***, otherwise you'd have thought we would have the most basic of features, sort by creation date, by now ;-) At the very least size taken by an entry should be visible on the details view. Right now there is zero indication other than just watching your total Journal grow in size via it's frame icon. ***Eben can you clarify this one? If locking folks into a 'view Journal only by modification date' was an intentional design choice? Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 06:40:37PM +0100, Gary C Martin wrote: > On 3 Jul 2009, at 06:13, Aleksey Lim wrote: > >> On Fri, Jul 03, 2009 at 05:06:30AM +, Aleksey Lim wrote: >>> On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote: On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: > * additional types of filters > for example Library has[2] several types to filter objects > > * user tags > * object traits(additional columns from previous section) like > author, >genre, date for books > * activity creators(grouping by activity_id field) > * types of objects(like top section in filter palette)[3] > * filter by participants > * filter by sources(if we are in shared mode) > > I'm not sure that all of these modes are useful, but something > could > be(or another types) like http://wiki.sugarlabs.org/go/File:-5.png >>> >>> use several types of view, list and cloud >>> http://wiki.sugarlabs.org/go/File:-6.png >> >> I guess, having numbers of objects makes sense as well >> http://wiki.sugarlabs.org/go/File:-7.png > > Yes if that information is easily/quickly available some may find that > use full, it might be too much information clutter though. Likely more > useful for the tag cloud, though I'd rather tag font size be used for > immediate visual comparison. Tag cloud mock-up is still in progress, > it'll go up on the wiki page as soon as it's done. yeah it was only for list view(of tags) cloud is all about font sizes instead of explicitly mentioned counts -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 06:36:07PM +0100, Gary C Martin wrote: > > On 3 Jul 2009, at 06:06, Aleksey Lim wrote: > >> On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote: >>> On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: * additional types of filters for example Library has[2] several types to filter objects * user tags * object traits(additional columns from previous section) like author, genre, date for books * activity creators(grouping by activity_id field) * types of objects(like top section in filter palette)[3] * filter by participants * filter by sources(if we are in shared mode) I'm not sure that all of these modes are useful, but something could be(or another types) >>> >>> like http://wiki.sugarlabs.org/go/File:-5.png >> >> use several types of view, list and cloud >> http://wiki.sugarlabs.org/go/File:-6.png > > I think we may now be talking about different features/options :-) > Apologies if so, but... > > "List view" (for me) is the top right toolbar icon already shown, it > shows all entries as a row list, as shown, and just like the current > Journal. We really think talking about different features/options :) I meant grouped list, for example if we chose users tags type of filter (ok, thats discussable:) this list will be a list of tags; if we chose object types type it will be a list of object types > "Cloud view" (for me) will be what you see (or something close) when you > click on that tag/label icon showing the main toolbar. It will show a > palette that display current Journal tags in an efficient space manor. yup, exactly what I mean here(and so for list view from prev. paragraph) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 06:13:24PM +0100, Gary C Martin wrote:
> Hi Aleksey,
>
> On 3 Jul 2009, at 05:25, Aleksey Lim wrote:
>> On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote:
>>> Aleksey was keen to see any Journal mock-up work in progress I had,
>>> early as possible, so here's where I'm at :-) There's plenty to do
>>> still, images are intended to help bounce ideas about, poke at the
>>> grey
>>> matter between our ears, and get a feel for how things could (or
>>> not) be
>>> done:
>>>
>>>
>>> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes
>>
>> Some thoughts:
>>
>> * what about adding ultra compact list view for objects(not actions)
>> like list view in Library[1]
>> the purpose is, if user has lots of objects it could be useful idea
>> to
>> show as much as possible objects on one screen
>
> We do want to show plenty of entries, but need to keep in mind visible
> size of each text/icon row entry. My current call is to make each
> Journal entry row 'richer' rather than trying to cram on more rows
> (encourage folks to search/filter down to a small number of results).
Maybe having several views/layouts(for several purposes) is more useful
idea then only one common view for all purposes? I mean:
* compact view
could be not trivial(horizontal scrolls) but highly
configured(show/hide columns)
for people who want narrow lines with additional columns
(to sort them for example)
* grid view
and use filters to show what user needs(because there could a lack
of useful info in this view)
> The grid view is better for looking and scrubbing through many entries.
> In Library you've made your rows richer by adding many more options for
> showing extra columns of information (author, artist, date, album, disk,
> track, genre, copyright, ...) at the cost of lots of horizontal
> scrolling, and option complexity.
>
>> * having several column/grid layouts
>>for example its very useful for books to have columns for author,
>>genre, date; so, user can see the whole valuable info at once and
>> sort
>>objects by these columns; and so separate layouts for video audio
>>etc. files
>
> The option complexity is too high for me, and causes horizontal
> scrolling (mentioned above), though the ability to sort on any arbitrary
> column is a bonus. Personally I think all the extra column information
> would be much better treated as tags, that way you can use the existing
> Journal tagging mechinisum, search and drill down to the entries you are
> after, and with the title + tag row entry still get to directly browse
> that information if needed.
>
>> * additional types of filters
>> for example Library has[2] several types to filter objects
>
> As a user, I don't like to see dot notation bundle id's displayed in the
> UI (i.e org.laptop.sugar.ReadEtextsActivity), it's way too scary :-) I
> think the anything/what activity/mime filter is more user friendly.
thats was just first implementation(further it will be activity names)
>> * user tags
>
> Library does confuse me here in that it seems to have it's on separate
> tagging data and process while ignoring actual Journal tag metadata.
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".
>> * object traits(additional columns from previous section) like
>> author,
>>genre, date for books
>
> Found this separation confusing, if really necessary, are 'traits' not
> just tags?
thats because they live in separate DS fields to let users sort objects
by them
>> * activity creators(grouping by activity_id field)
>
> Yes, I have a TODO to add a button and palette for anyone/who.
>
>> * types of objects(like top section in filter palette)[3]
>
> Yep, that's my anything/what funnel filter icon (looking for better
> icon) :-)
>
>> * filter by participants
>
> I see that as part of above anyone/who.
>The most common filter would be
> to be able to search for Journal entries from "Walter".
but in that case user would get all objects with substring "Walter"
not only objects with participant Walter
>> * filter by sources(if we are in shared mode)
>
> For your Library Activity, but not sure this is relevant (in short to
> mid term) for Journal. And, perhaps covered by above anyone/who filter.
> Once you 'borrow' an entry you now have a local copy in the user colours
> of the person you borrowed from.
yeah, thats should rethinking during implementation of sharing objects
>> I'm not sure that all of these modes are useful, but something could
>> be(or another types)
>>
>> * several levels of chosen filt
Re: [Sugar-devel] Journal feature request--more data in main display
On 3 Jul 2009, at 06:13, Aleksey Lim wrote: > On Fri, Jul 03, 2009 at 05:06:30AM +, Aleksey Lim wrote: >> On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote: >>> On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: * additional types of filters for example Library has[2] several types to filter objects * user tags * object traits(additional columns from previous section) like author, genre, date for books * activity creators(grouping by activity_id field) * types of objects(like top section in filter palette)[3] * filter by participants * filter by sources(if we are in shared mode) I'm not sure that all of these modes are useful, but something could be(or another types) >>> >>> like http://wiki.sugarlabs.org/go/File:-5.png >> >> use several types of view, list and cloud >> http://wiki.sugarlabs.org/go/File:-6.png > > I guess, having numbers of objects makes sense as well > http://wiki.sugarlabs.org/go/File:-7.png Yes if that information is easily/quickly available some may find that use full, it might be too much information clutter though. Likely more useful for the tag cloud, though I'd rather tag font size be used for immediate visual comparison. Tag cloud mock-up is still in progress, it'll go up on the wiki page as soon as it's done. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 3 Jul 2009, at 06:06, Aleksey Lim wrote: > On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote: >> On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: >>> * additional types of filters >>> for example Library has[2] several types to filter objects >>> >>> * user tags >>> * object traits(additional columns from previous section) like >>> author, >>>genre, date for books >>> * activity creators(grouping by activity_id field) >>> * types of objects(like top section in filter palette)[3] >>> * filter by participants >>> * filter by sources(if we are in shared mode) >>> >>> I'm not sure that all of these modes are useful, but something >>> could >>> be(or another types) >> >> like http://wiki.sugarlabs.org/go/File:-5.png > > use several types of view, list and cloud > http://wiki.sugarlabs.org/go/File:-6.png I think we may now be talking about different features/options :-) Apologies if so, but... "List view" (for me) is the top right toolbar icon already shown, it shows all entries as a row list, as shown, and just like the current Journal. "Cloud view" (for me) will be what you see (or something close) when you click on that tag/label icon showing the main toolbar. It will show a palette that display current Journal tags in an efficient space manor. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 3 Jul 2009, at 05:53, Aleksey Lim wrote: > On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: >> * additional types of filters >> for example Library has[2] several types to filter objects >> >> * user tags >> * object traits(additional columns from previous section) like >> author, >>genre, date for books >> * activity creators(grouping by activity_id field) >> * types of objects(like top section in filter palette)[3] >> * filter by participants >> * filter by sources(if we are in shared mode) >> >> I'm not sure that all of these modes are useful, but something could >> be(or another types) > > like http://wiki.sugarlabs.org/go/File:-5.png The filters (currently in Journal, and in my mock-ups) are in separate top level toolbar controls. I'm basically just switching them to icons instead of text menus. From your mock-up, "User tags" would be controlled via a palette (not yet finished the mock-up) from that tag/ label icon shown in the toolbar. Next to it will also be added a buddy icon (white outline) for a filter palette (not yet finished the mock- up) that looks like it would cover "Participants". Where you have "Object types" I understand that as file mime types, which was what I placed at the top of that palette before your mock-up modification :-) Your "Object traits" I thing a best just dealt with in a universal way as tags, no new ontology needed and gets to benefit from any general tag improvements we make to Sugar (details entry, activity naming dialogue improvements, auto completion, 'tags under title' Journal entry display, the Object Chooser). I'm not convinced I understand your "Creators" category. Is this original author, the Activity used to build the entry, or something else? Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
Hi Aleksey, On 3 Jul 2009, at 05:25, Aleksey Lim wrote: > On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote: >> Aleksey was keen to see any Journal mock-up work in progress I had, >> early as possible, so here's where I'm at :-) There's plenty to do >> still, images are intended to help bounce ideas about, poke at the >> grey >> matter between our ears, and get a feel for how things could (or >> not) be >> done: >> >> >> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes > > Some thoughts: > > * what about adding ultra compact list view for objects(not actions) > like list view in Library[1] > the purpose is, if user has lots of objects it could be useful idea > to > show as much as possible objects on one screen We do want to show plenty of entries, but need to keep in mind visible size of each text/icon row entry. My current call is to make each Journal entry row 'richer' rather than trying to cram on more rows (encourage folks to search/filter down to a small number of results). The grid view is better for looking and scrubbing through many entries. In Library you've made your rows richer by adding many more options for showing extra columns of information (author, artist, date, album, disk, track, genre, copyright, ...) at the cost of lots of horizontal scrolling, and option complexity. > * having several column/grid layouts >for example its very useful for books to have columns for author, >genre, date; so, user can see the whole valuable info at once and > sort >objects by these columns; and so separate layouts for video audio >etc. files The option complexity is too high for me, and causes horizontal scrolling (mentioned above), though the ability to sort on any arbitrary column is a bonus. Personally I think all the extra column information would be much better treated as tags, that way you can use the existing Journal tagging mechinisum, search and drill down to the entries you are after, and with the title + tag row entry still get to directly browse that information if needed. > * additional types of filters > for example Library has[2] several types to filter objects As a user, I don't like to see dot notation bundle id's displayed in the UI (i.e org.laptop.sugar.ReadEtextsActivity), it's way too scary :-) I think the anything/what activity/mime filter is more user friendly. > * user tags Library does confuse me here in that it seems to have it's on separate tagging data and process while ignoring actual Journal tag metadata. > * object traits(additional columns from previous section) like > author, >genre, date for books Found this separation confusing, if really necessary, are 'traits' not just tags? > * activity creators(grouping by activity_id field) Yes, I have a TODO to add a button and palette for anyone/who. > * types of objects(like top section in filter palette)[3] Yep, that's my anything/what funnel filter icon (looking for better icon) :-) > * filter by participants I see that as part of above anyone/who. The most common filter would be to be able to search for Journal entries from "Walter". > * filter by sources(if we are in shared mode) For your Library Activity, but not sure this is relevant (in short to mid term) for Journal. And, perhaps covered by above anyone/who filter. Once you 'borrow' an entry you now have a local copy in the user colours of the person you borrowed from. > I'm not sure that all of these modes are useful, but something could > be(or another types) > > * several levels of chosen filters > dunno about others but for me its very useful > (see bottom panel on [4]) > for example I can filter all text/plane files and separate from them > only objects that were made by Terminal activity I found this complicated in Library, actually I'm not sure I have is solved yet :-) I think tagging is a simple wide ranging panacea for many of these types of search. > [1] http://wiki.sugarlabs.org/go/File:-3.png > [2] http://wiki.sugarlabs.org/go/File:-1.png > [3] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#.232 > [4] http://wiki.sugarlabs.org/go/File:-4.png I have Library-1 as per activities.sugarlabs.org but my screens look slightly different to your screenshots (you have more side bar icons than I see). Is there another version I should be looking at? Thanks for all the feedback! --Gary P.S. I'm still hacking on the http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes mock-ups, so this is all great stuff to keep in mind while I tweak. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 3, 2009 at 11:01, Martin Langhoff wrote: > On Fri, Jul 3, 2009 at 5:29 AM, Gary C Martin wrote: >> Aleksey was keen to see any Journal mock-up work in progress I had, >> early as possible, so here's where I'm at :-) There's plenty to do >> still, images are intended to help bounce ideas about, poke at the >> grey matter between our ears, and get a feel for how things could (or >> not) be done: >> >> >> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes > > Very cool. I do agree the filter is very culture-dependent. > > On a similar vein, the 'tag' icon has no visual association with the > many tags on screen. If they had a similar shape, then it'd be easy to > connect, for users who don't recognise a "tag" and the (somewhat odd) > use of "tag" to mean "a bit of metadata on a digital resource". > > Wishlist: "show files by size" filter or option? I think that's a good idea. Could we have a ticket for it? And maybe also a shorter term one to display the file size somewhere? Thanks, Tomeu > If the Uruguay > experience is any indicator, a fact of life is that users after all > *will* hit: > > - problems with fitting files (large and small) in USB disks > > - problems with their Journal taking too much space > > - problems with installed Activities taking too much disk space > > cheers, > > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 11:01:25AM +0200, Martin Langhoff wrote: > On Fri, Jul 3, 2009 at 5:29 AM, Gary C Martin wrote: > > Aleksey was keen to see any Journal mock-up work in progress I had, > > early as possible, so here's where I'm at :-) There's plenty to do > > still, images are intended to help bounce ideas about, poke at the > > grey matter between our ears, and get a feel for how things could (or > > not) be done: > > > > > > http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes > > Very cool. I do agree the filter is very culture-dependent. > > On a similar vein, the 'tag' icon has no visual association with the > many tags on screen. If they had a similar shape, then it'd be easy to > connect, for users who don't recognise a "tag" and the (somewhat odd) > use of "tag" to mean "a bit of metadata on a digital resource". > > Wishlist: "show files by size" filter or option? If the Uruguay > experience is any indicator, a fact of life is that users after all > *will* hit: > > - problems with fitting files (large and small) in USB disks > > - problems with their Journal taking too much space > > - problems with installed Activities taking too much disk space It could be utilized in different list view layout some of[1] these layout could have column for size and users can sort by this column. [1] http://wiki.sugarlabs.org/go/File:-3.png -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Thu, Jul 2, 2009 at 03:40, Gary C Martin wrote: > On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote: >> >> On Mon, Jun 29, 2009 at 18:14, Gary C Martin wrote: >>> >>> - Showing tags under the title would be great (Tomeu, I will help where I >>> can) >> >> Hope to push my work on the journal treeview soon, then you can take >> it and do whatever graphics modifications you want. > > Fab. > >>> - Batch entry modification (FWIW, don't like the tick box, that feels >>> like >>> an old school html web form hack) >> >> Any alternative? > > I see multi selection Journal operations as a more advanced (occasional use) > feature, so it would be OK not being directly visually exposed. So, no tick > box column (save all that space for useful information), instead use a shift > key modifier so that when clicking an entry its selection state is toggled > on/off (grey backing fill of the entry row). When hovering over (or right > clicking) a multi selected entry, display a new palette with just the > features that function on a multiple selection. "Erase" being the obvious > multiple selection command asked for in the past; the other useful multiple > selection function would be drag and drop for copying a batch of Journal > entries to and from external media (i.e. teacher comes back from the city > with a USB stick full of downloaded ebooks). gtk.TreeViews have multiple selection support. Would be very cool if someone could play with the several options and report back: http://www.pygtk.org/docs/pygtk/class-gtktreeview.html#method-gtktreeview--set-rubber-banding Some tweaking of the gtk theme may be needed to make it look right. >>> - Better Anything toolbar filter palette (use a grid layout to minimise >>> scrolling) >> >> Yeah, that will be great. I think Walter already submitted a patch to >> move the file types up. > > Yea, saw the patch from Walter, that alone should help even if we stall on > doing more. > > I have a mock-up I was experimenting with grid layouts, still tinkering, and > I can't think of a good 'filter' icon for the replacement button (a common > one seems to be a funnel shape) :-) > > The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone', and my > below 'Tag' filters can all become toolbar icons (not text). This saves a > heap of toolbar space, and allows room for a couple more buttons on the far > right for 'Grid' and current 'List' view. Awesome, have high hopes about that. Regards, Tomeu >>> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) >> >> Could you draw a quick napkin mockup to illustrate that? > > > Sure, but don't think I'll have anything in time for the dev meeting. > > Regards, > --Gary > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 3, 2009 at 5:29 AM, Gary C Martin wrote: > Aleksey was keen to see any Journal mock-up work in progress I had, > early as possible, so here's where I'm at :-) There's plenty to do > still, images are intended to help bounce ideas about, poke at the > grey matter between our ears, and get a feel for how things could (or > not) be done: > > > http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes Very cool. I do agree the filter is very culture-dependent. On a similar vein, the 'tag' icon has no visual association with the many tags on screen. If they had a similar shape, then it'd be easy to connect, for users who don't recognise a "tag" and the (somewhat odd) use of "tag" to mean "a bit of metadata on a digital resource". Wishlist: "show files by size" filter or option? If the Uruguay experience is any indicator, a fact of life is that users after all *will* hit: - problems with fitting files (large and small) in USB disks - problems with their Journal taking too much space - problems with installed Activities taking too much disk space cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 05:06:30AM +, Aleksey Lim wrote: > On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote: > > On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: > > > * additional types of filters > > > for example Library has[2] several types to filter objects > > > > > > * user tags > > > * object traits(additional columns from previous section) like author, > > > genre, date for books > > > * activity creators(grouping by activity_id field) > > > * types of objects(like top section in filter palette)[3] > > > * filter by participants > > > * filter by sources(if we are in shared mode) > > > > > > I'm not sure that all of these modes are useful, but something could > > > be(or another types) > > > > like http://wiki.sugarlabs.org/go/File:-5.png > > use several types of view, list and cloud > http://wiki.sugarlabs.org/go/File:-6.png I guess, having numbers of objects makes sense as well http://wiki.sugarlabs.org/go/File:-7.png -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote: > On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: > > * additional types of filters > > for example Library has[2] several types to filter objects > > > > * user tags > > * object traits(additional columns from previous section) like author, > > genre, date for books > > * activity creators(grouping by activity_id field) > > * types of objects(like top section in filter palette)[3] > > * filter by participants > > * filter by sources(if we are in shared mode) > > > > I'm not sure that all of these modes are useful, but something could > > be(or another types) > > like http://wiki.sugarlabs.org/go/File:-5.png use several types of view, list and cloud http://wiki.sugarlabs.org/go/File:-6.png Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: > * additional types of filters > for example Library has[2] several types to filter objects > > * user tags > * object traits(additional columns from previous section) like author, > genre, date for books > * activity creators(grouping by activity_id field) > * types of objects(like top section in filter palette)[3] > * filter by participants > * filter by sources(if we are in shared mode) > > I'm not sure that all of these modes are useful, but something could > be(or another types) like http://wiki.sugarlabs.org/go/File:-5.png -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote: > On 2 Jul 2009, at 02:40, Gary C Martin wrote: > >> On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote: >>> On Mon, Jun 29, 2009 at 18:14, Gary C Martin >>> wrote: - Better Anything toolbar filter palette (use a grid layout to minimise scrolling) >>> >>> Yeah, that will be great. I think Walter already submitted a patch to >>> move the file types up. >> >> Yea, saw the patch from Walter, that alone should help even if we >> stall on doing more. >> >> I have a mock-up I was experimenting with grid layouts, still >> tinkering, and I can't think of a good 'filter' icon for the >> replacement button (a common one seems to be a funnel shape) :-) >> >> The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone', >> and my below 'Tag' filters can all become toolbar icons (not text). >> This saves a heap of toolbar space, and allows room for a couple more >> buttons on the far right for 'Grid' and current 'List' view. > > Aleksey was keen to see any Journal mock-up work in progress I had, > early as possible, so here's where I'm at :-) There's plenty to do > still, images are intended to help bounce ideas about, poke at the grey > matter between our ears, and get a feel for how things could (or not) be > done: > > > http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes Some thoughts: * what about adding ultra compact list view for objects(not actions) like list view in Library[1] the purpose is, if user has lots of objects it could be useful idea to show as much as possible objects on one screen * having several column/grid layouts for example its very useful for books to have columns for author, genre, date; so, user can see the whole valuable info at once and sort objects by these columns; and so separate layouts for video audio etc. files * additional types of filters for example Library has[2] several types to filter objects * user tags * object traits(additional columns from previous section) like author, genre, date for books * activity creators(grouping by activity_id field) * types of objects(like top section in filter palette)[3] * filter by participants * filter by sources(if we are in shared mode) I'm not sure that all of these modes are useful, but something could be(or another types) * several levels of chosen filters dunno about others but for me its very useful (see bottom panel on [4]) for example I can filter all text/plane files and separate from them only objects that were made by Terminal activity [1] http://wiki.sugarlabs.org/go/File:-3.png [2] http://wiki.sugarlabs.org/go/File:-1.png [3] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#.232 [4] http://wiki.sugarlabs.org/go/File:-4.png -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 2 Jul 2009, at 02:40, Gary C Martin wrote: > On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote: >> On Mon, Jun 29, 2009 at 18:14, Gary C Martin >> wrote: >>> - Better Anything toolbar filter palette (use a grid layout to >>> minimise >>> scrolling) >> >> Yeah, that will be great. I think Walter already submitted a patch to >> move the file types up. > > Yea, saw the patch from Walter, that alone should help even if we > stall on doing more. > > I have a mock-up I was experimenting with grid layouts, still > tinkering, and I can't think of a good 'filter' icon for the > replacement button (a common one seems to be a funnel shape) :-) > > The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone', > and my below 'Tag' filters can all become toolbar icons (not text). > This saves a heap of toolbar space, and allows room for a couple more > buttons on the far right for 'Grid' and current 'List' view. Aleksey was keen to see any Journal mock-up work in progress I had, early as possible, so here's where I'm at :-) There's plenty to do still, images are intended to help bounce ideas about, poke at the grey matter between our ears, and get a feel for how things could (or not) be done: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes Regards, --Gary P.S. Please, anyone have a better idea for an 'Anything' icon kicking about? I'll be darned if I'm leaving the filter/funnel icon in place very long (but it does seem fairly standard for a filter graphic)... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote: > On Mon, Jun 29, 2009 at 18:14, Gary C Martin > wrote: >> - Showing tags under the title would be great (Tomeu, I will help >> where I >> can) > > Hope to push my work on the journal treeview soon, then you can take > it and do whatever graphics modifications you want. Fab. >> - Batch entry modification (FWIW, don't like the tick box, that >> feels like >> an old school html web form hack) > > Any alternative? I see multi selection Journal operations as a more advanced (occasional use) feature, so it would be OK not being directly visually exposed. So, no tick box column (save all that space for useful information), instead use a shift key modifier so that when clicking an entry its selection state is toggled on/off (grey backing fill of the entry row). When hovering over (or right clicking) a multi selected entry, display a new palette with just the features that function on a multiple selection. "Erase" being the obvious multiple selection command asked for in the past; the other useful multiple selection function would be drag and drop for copying a batch of Journal entries to and from external media (i.e. teacher comes back from the city with a USB stick full of downloaded ebooks). >> - Better Anything toolbar filter palette (use a grid layout to >> minimise >> scrolling) > > Yeah, that will be great. I think Walter already submitted a patch to > move the file types up. Yea, saw the patch from Walter, that alone should help even if we stall on doing more. I have a mock-up I was experimenting with grid layouts, still tinkering, and I can't think of a good 'filter' icon for the replacement button (a common one seems to be a funnel shape) :-) The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone', and my below 'Tag' filters can all become toolbar icons (not text). This saves a heap of toolbar space, and allows room for a couple more buttons on the far right for 'Grid' and current 'List' view. >> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) > > Could you draw a quick napkin mockup to illustrate that? Sure, but don't think I'll have anything in time for the dev meeting. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Tue, Jun 30, 2009 at 19:02, Gary C Martin wrote: > On 30 Jun 2009, at 00:32, Michael Stone wrote: > > -- big snip from old thread --- > >>> - Better Anything toolbar filter palette (use a grid layout to >>> minimise scrolling) >> >> How do you think >> >> http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars >> >> would work out here? > > An 'Anything' filter button opening a palette with a grid layout of > filter options could work as is right now. It could be a relatively > small and contained code change, for a relatively large improvement in > usability. I guess (in Ebens toolbar mock-ups) a pop-up row could be > filled with the same filter options, but it would need to cope with > multi row layouts as the number of filter options grows over time > (i.e. as more Activities are installed). > > More generally regarding the toolbar mock-ups, some points needing > clarification: > > - Stop button must be visible at ALL times, none of these mock-ups > show a stop > - Activity collaboration control has disappeared, assume this should > be a primary icon > - No solution yet for textual names/labels (inventing unique and clear > icons is going to get real tough, real fast, and many Activity authors > already struggle creating decent activity icons). > - Activity title has disappeared from toolbar is that intentional to > rely on the naming dialogue every-time? Yup, I guess one more refining step would be needed to move forward. > Being Mr ActivityTeam at the moment, I do really worry about the > amount of work this is going to be to get Activities updated and > complying to a large toolbar redesign. Supporting both toolbar API > styles will help, but I think we'll end up with multiple toolbar > styles in different Activities for perhaps 6 months to a year or more. > That's a bad backward step for usability. Just look at the amount of > time/effort it is taking to migrate Activities over to SL > infrastructure, let alone making anything but minor maintenance code > changes to them. True, so what do you suggest here? Thanks, Tomeu >>> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) >> >> What do you think of Scott's journal2 design here? > > Technically? A massive redesign requiring a rock-star lead developer > and a long-term commitment to refine, debug, and stabilise over > several Sugar platform release cycles. There are nice ideas in there, > I particularly like the idea of turning directory paths into tags as a > way to access the file system. But, a much simpler option would be to > let a user type something like "/usr/local/..." in the existing > Journal search and have the Journal display a basic folders/files > view, typing just "/" would show the root level and a user could > navigate old school style from there. Copy/paste could be extended to > move content between Journal/file-system views, and external devices > could show the file-system view by default so a USB key or SD card > could be more easily managed. > > Regards, > --Gary > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jun 29, 2009 at 18:14, Gary C Martin wrote: > On 29 Jun 2009, at 16:07, Tomeu Vizoso wrote: > >> On Mon, Jun 29, 2009 at 16:55, Aleksey Lim wrote: >>> >>> On Sun, Jun 21, 2009 at 02:39:22PM -0700, Edward Cherlin wrote: We have about 60 characters worth of blank space in every Journal entry. It would be a great help if we could display 40-50 characters from the description field for each entry on the main page. We could also drop off the word Activity from every Activity name. >>> >>> maybe using several views >>> * one line view >>> * full view(multi lined view) >>> * thumbs >>> >>> btw I hope we'll decide to work on all these object list related >>> features in one place, now we have Journal, Library(partially >>> implemented) >>> and not implemented Dairy(http://erikos.sweettimez.de/?p=742) >> >> Yup, I personally love the mockups at >> http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal . >> >> Other opinions? > > I like the intent, but I don't think the "activity centric" view has > concrete enough spec to consider implementing yet. There is just way too > much magic sauce in those mock-ups to my mind. The closest I've seen > something like this implemented, is with Apple's iPhoto, where imported > photos are auto arranged into single expandable "events" based on each > photos date/time metadata. You're given a couple of preferences for > adjusting the granularity (one event per week, one event per day, one event > per 8hrs, one event per 2hrs). Works quite well most of the time, you can > always manually merge two events into one, or split one event into two, if > it gets them wrong. I don't see that as so problematic. Activities are already saving the items that go to the Objects view, we just may need (or not) to remove some of the metadata and make them more document-like. About the Actions view, we have a baseline for activities that is "Worked on Paint for 15 minutes". But activities would be free to change that to whatever makes most sense. I can see how the shell would have a very hard time guessing how best to represent what the user did in activities, but activities have much more information and I think it's where we should put this logic. > I guess we could make the "activity centric" view work in the same way, a > fixed time slice that rolls up N hrs work into a collapsable/expandable > block that the user can custom name (and/or some auto name based on the > content). Not sure we would need that, but we could use Projects as containers ;) > The still raises lot's of questions, what happens when you resume some image > you painted from way back to take a quick look? Where does it now show in > activity centric view? Does it get removed from its old block positioning > and to some new active block; perhaps it get multi-linked so now appears > twice (you can still find it in the original old place and also find it in > new place)? I see past actions as immutable. In that case a new action entry would be added, and if the Paint activity wishes, it can label it "Looked at paint 'My house'" if it detects that no change happened. Or it can just not create any entry if it makes most sense from that point of view. > -=-=-=-=-=- > > The grid/thumb view should be a top level button, not as is shown buried in > a sub palette here: > > http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#09 > > I'd consider 2 primary view type buttons: > > 1). List view, just as we get now > 2). Grid view, much like as implemented in Library Sure, I don't see those mockups as a detailed spec for implementing right now, but I think they explain some very exciting ideas for moving forward. > -=-=-=-=-=- > > Having said all this, it seems sensible to pick a few solid Journal > improvements and just make some robust steps forward, like: Totally agreed! > - Showing tags under the title would be great (Tomeu, I will help where I > can) Hope to push my work on the journal treeview soon, then you can take it and do whatever graphics modifications you want. > - Batch entry modification (FWIW, don't like the tick box, that feels like > an old school html web form hack) Any alternative? > - Better Anything toolbar filter palette (use a grid layout to minimise > scrolling) Yeah, that will be great. I think Walter already submitted a patch to move the file types up. > - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) Could you draw a quick napkin mockup to illustrate that? Thanks, Tomeu > Regards, > --Gary > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 30 Jun 2009, at 00:32, Michael Stone wrote: -- big snip from old thread --- >> - Better Anything toolbar filter palette (use a grid layout to >> minimise scrolling) > > How do you think > > http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars > > would work out here? An 'Anything' filter button opening a palette with a grid layout of filter options could work as is right now. It could be a relatively small and contained code change, for a relatively large improvement in usability. I guess (in Ebens toolbar mock-ups) a pop-up row could be filled with the same filter options, but it would need to cope with multi row layouts as the number of filter options grows over time (i.e. as more Activities are installed). More generally regarding the toolbar mock-ups, some points needing clarification: - Stop button must be visible at ALL times, none of these mock-ups show a stop - Activity collaboration control has disappeared, assume this should be a primary icon - No solution yet for textual names/labels (inventing unique and clear icons is going to get real tough, real fast, and many Activity authors already struggle creating decent activity icons). - Activity title has disappeared from toolbar is that intentional to rely on the naming dialogue every-time? Being Mr ActivityTeam at the moment, I do really worry about the amount of work this is going to be to get Activities updated and complying to a large toolbar redesign. Supporting both toolbar API styles will help, but I think we'll end up with multiple toolbar styles in different Activities for perhaps 6 months to a year or more. That's a bad backward step for usability. Just look at the amount of time/effort it is taking to migrate Activities over to SL infrastructure, let alone making anything but minor maintenance code changes to them. >> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) > > What do you think of Scott's journal2 design here? Technically? A massive redesign requiring a rock-star lead developer and a long-term commitment to refine, debug, and stabilise over several Sugar platform release cycles. There are nice ideas in there, I particularly like the idea of turning directory paths into tags as a way to access the file system. But, a much simpler option would be to let a user type something like "/usr/local/..." in the existing Journal search and have the Journal display a basic folders/files view, typing just "/" would show the root level and a user could navigate old school style from there. Copy/paste could be extended to move content between Journal/file-system views, and external devices could show the file-system view by default so a USB key or SD card could be more easily managed. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Tue, Jun 30, 2009 at 08:46:56AM -0400, Eben Eliason wrote: > On Tue, Jun 30, 2009 at 8:20 AM, Aleksey Lim wrote: > > On Mon, Jun 29, 2009 at 08:59:30PM -0400, Eben Eliason wrote: > >> On Mon, Jun 29, 2009 at 8:14 PM, Edward Cherlin wrote: > >> > I would be interested to see this applied to a few dozen common > >> > workflows, such as student portfolios, a business plan, a lesson plan, > >> > a textbook incorporating software models, a research report, a photo > >> > album with pictures extracted from different sessions by different > >> > people, or downloaded from somewhere, and so on. If we knew what > >> > workflows our teachers and students needed, we would have a better > >> > chance of designing something that met their needs. > >> > >> We weren't trying, while designing this, to get too deep into lots > >> organizational models. Instead, we were trying to capture "sessions" > >> as actions which reference one or more objects, where a session, or an > >> action, is basically one continuous use of a given activity. In the > >> case of record, this might create several photos (separate objects), > >> which get grouped into the action. Most activities would have a 1-1 > >> association with objects, but not all. > >> > >> This also gives us a way to describe actions other than "working in an > >> activity." For instance, we might have an action for "copy _object_ to > >> _flash_", "sent _object_ to_person_", or "received _object_ from > >> _person_". Also, things like "became friends with _person_" and > >> "joined _group_" would be great to have. We could have "installed > >> _activity_" and "updated _activity_" actions. Etc. > > > > A couple of related questions. > > How the process of "recording" these sessions/activities should look? > > I think the standard procedure for creating an action is the usual > process of starting or resuming an activity, working with that > activity for some duration, and then stopping the activity again. This > series of steps will normally result in a single action. (Pressing > "keep" manually would introduce additional ones.) Most likely, the > Journal/DS would create an action and provide that to the activity to > add to as needed. Record, for instance, would periodically add new > image objects to that action. > If it so desired, an activity could also > request a new action from the Journal. maybe we should keep action related maintenance only user driven and do not let activities implicitly create new actions? btw "action" and "activity" sounds similar maybe using something like "record" or "session"? erikos: and looks like these actions are the same that Dairy activity should be > > Should we treat current state of the shell like a current session and > > what would happen if we restore to this current state another session > > from Journal? > > Less frequently, actions would be recorded by the shell for things > like making friends, copying/sending/receiving objects, etc. These > actions are basically just containers which reference the related > objects. Some, such as making friends, might not even reference an > object at all (though it might be nice to introduce people as objects > with entries in the Journal (like address book cards in the future). in my mind action like "making friends" goes rather to implementing undo then to actions, I think its a good idea to keep actions only DS-objects/activity-instances related to keep things consistent. > I don't think the state of the shell as a whole is tied into these > types of actions. We might consider extending action-space to include > things like "backed up _your journal_ to school server." Here, I > suppose it could be possible to initiate some kind of restore > operation. Or, perhaps "deleted 12 objects" (where deletions within a > reasonable time span are aggregated). We could also have things like > "changed your colors from _this_ to _this" and "changed your preferred > language setting to _language_." But none of these are really > "resumable". Instead, they just convey a meaningful change of state. > We could think about ways to enable "undo" functionality from actions > like these, but that's a fundamentally different idea from resuming a > session. > > Eben > > >> > >> Browse might reference any downloaded objects, in addition to it's > >> session "instance". We can give activities the freedom to use this as > >> they see fit. > >> > >> As seen here (http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#01), > >> we might also distinguish between viewing and modifying objects. If I > >> read a document without making edits to it, we could say as much, and > >> that action would reference the same version of the same object as > >> another action. > > > > -- > > Aleksey > > > -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Tue, Jun 30, 2009 at 8:20 AM, Aleksey Lim wrote: > On Mon, Jun 29, 2009 at 08:59:30PM -0400, Eben Eliason wrote: >> On Mon, Jun 29, 2009 at 8:14 PM, Edward Cherlin wrote: >> > I would be interested to see this applied to a few dozen common >> > workflows, such as student portfolios, a business plan, a lesson plan, >> > a textbook incorporating software models, a research report, a photo >> > album with pictures extracted from different sessions by different >> > people, or downloaded from somewhere, and so on. If we knew what >> > workflows our teachers and students needed, we would have a better >> > chance of designing something that met their needs. >> >> We weren't trying, while designing this, to get too deep into lots >> organizational models. Instead, we were trying to capture "sessions" >> as actions which reference one or more objects, where a session, or an >> action, is basically one continuous use of a given activity. In the >> case of record, this might create several photos (separate objects), >> which get grouped into the action. Most activities would have a 1-1 >> association with objects, but not all. >> >> This also gives us a way to describe actions other than "working in an >> activity." For instance, we might have an action for "copy _object_ to >> _flash_", "sent _object_ to_person_", or "received _object_ from >> _person_". Also, things like "became friends with _person_" and >> "joined _group_" would be great to have. We could have "installed >> _activity_" and "updated _activity_" actions. Etc. > > A couple of related questions. > How the process of "recording" these sessions/activities should look? I think the standard procedure for creating an action is the usual process of starting or resuming an activity, working with that activity for some duration, and then stopping the activity again. This series of steps will normally result in a single action. (Pressing "keep" manually would introduce additional ones.) Most likely, the Journal/DS would create an action and provide that to the activity to add to as needed. Record, for instance, would periodically add new image objects to that action. If it so desired, an activity could also request a new action from the Journal. > Should we treat current state of the shell like a current session and > what would happen if we restore to this current state another session > from Journal? Less frequently, actions would be recorded by the shell for things like making friends, copying/sending/receiving objects, etc. These actions are basically just containers which reference the related objects. Some, such as making friends, might not even reference an object at all (though it might be nice to introduce people as objects with entries in the Journal (like address book cards in the future). I don't think the state of the shell as a whole is tied into these types of actions. We might consider extending action-space to include things like "backed up _your journal_ to school server." Here, I suppose it could be possible to initiate some kind of restore operation. Or, perhaps "deleted 12 objects" (where deletions within a reasonable time span are aggregated). We could also have things like "changed your colors from _this_ to _this" and "changed your preferred language setting to _language_." But none of these are really "resumable". Instead, they just convey a meaningful change of state. We could think about ways to enable "undo" functionality from actions like these, but that's a fundamentally different idea from resuming a session. Eben >> >> Browse might reference any downloaded objects, in addition to it's >> session "instance". We can give activities the freedom to use this as >> they see fit. >> >> As seen here (http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#01), >> we might also distinguish between viewing and modifying objects. If I >> read a document without making edits to it, we could say as much, and >> that action would reference the same version of the same object as >> another action. > > -- > Aleksey > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jun 29, 2009 at 08:59:30PM -0400, Eben Eliason wrote: > On Mon, Jun 29, 2009 at 8:14 PM, Edward Cherlin wrote: > > I would be interested to see this applied to a few dozen common > > workflows, such as student portfolios, a business plan, a lesson plan, > > a textbook incorporating software models, a research report, a photo > > album with pictures extracted from different sessions by different > > people, or downloaded from somewhere, and so on. If we knew what > > workflows our teachers and students needed, we would have a better > > chance of designing something that met their needs. > > We weren't trying, while designing this, to get too deep into lots > organizational models. Instead, we were trying to capture "sessions" > as actions which reference one or more objects, where a session, or an > action, is basically one continuous use of a given activity. In the > case of record, this might create several photos (separate objects), > which get grouped into the action. Most activities would have a 1-1 > association with objects, but not all. > > This also gives us a way to describe actions other than "working in an > activity." For instance, we might have an action for "copy _object_ to > _flash_", "sent _object_ to_person_", or "received _object_ from > _person_". Also, things like "became friends with _person_" and > "joined _group_" would be great to have. We could have "installed > _activity_" and "updated _activity_" actions. Etc. A couple of related questions. How the process of "recording" these sessions/activities should look? Should we treat current state of the shell like a current session and what would happen if we restore to this current state another session from Journal? > > Browse might reference any downloaded objects, in addition to it's > session "instance". We can give activities the freedom to use this as > they see fit. > > As seen here (http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#01), > we might also distinguish between viewing and modifying objects. If I > read a document without making edits to it, we could say as much, and > that action would reference the same version of the same object as > another action. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jun 29, 2009 at 8:14 PM, Edward Cherlin wrote: > Oh, Michael, you're in trouble now. ^_^ > > You risk reinventing the data-centric Ontology in an Object-Oriented > Programming form. This is one of the worst sinks for time and mental > energy that I know of. It saps the will, because soon users become > obsessed with making the map match the territory, when in reality > everybody wants to make different maps in different territories. > > Still, we have to do something along these lines. If we actually do it > as OOP, not just in OOP, so that users can redefine the classes, we > might get somewhere without turning our minds to stone. Maybe we can > make it into a pattern language? > > On Mon, Jun 29, 2009 at 4:32 PM, Michael Stone wrote: >> >> Gary C. Martin wrote: >> >>> I like the intent, but I don't think the "activity centric" view has >>> concrete enough spec to consider implementing yet. >> >> I want to convince you that we actually have enough detail to make forward >> progress with. >> >> To that end, I'm going to offer a bunch of text on how I think this display >> is >> supposed to work. >> >> You should go through it to identify >> >> a) things that don't make sense >> b) things that are disputed or where I'm obviously wrong >> c) things that are insufficiently specified >> >> and we should try to fix those. >> >> Then we'll be ready to do another round of discussion and prototyping. >> >> Regards, >> >> Michael >> >> --- >> >> The best picture I've ever extracted from people on this subject looks like >> this: >> >> Mental Picture of the Experience of Recording Butterflies >> >> >> * - action >> / \ >> instance - / \ >> \ / \ >> *--/ /--*---* - object container >> / | //\\\ >> bundle | / | \\\ >> / / | | \\ >> prototype / | | | \ >> * * * * * - objects > > I'm with you on actions, object containers and objects, but I don't > know what the instance arrow is pointing to, nor what bundles and > prototypes would be here. Is a prototype a structure for a particular > kind of collection, such as a portfolio outline? The bundle is a reference to the activity bundle used to create the action. The distinction between instance and prototype here is blurry to me, but the general idea is that we have something which represents the "session continuation" which, when clicked, restores the session by resuming object with the activity used to create it along with any relevant metadata. This is basically the description of what we *currently* do with activity icons in entries. > I would be interested to see this applied to a few dozen common > workflows, such as student portfolios, a business plan, a lesson plan, > a textbook incorporating software models, a research report, a photo > album with pictures extracted from different sessions by different > people, or downloaded from somewhere, and so on. If we knew what > workflows our teachers and students needed, we would have a better > chance of designing something that met their needs. We weren't trying, while designing this, to get too deep into lots organizational models. Instead, we were trying to capture "sessions" as actions which reference one or more objects, where a session, or an action, is basically one continuous use of a given activity. In the case of record, this might create several photos (separate objects), which get grouped into the action. Most activities would have a 1-1 association with objects, but not all. This also gives us a way to describe actions other than "working in an activity." For instance, we might have an action for "copy _object_ to _flash_", "sent _object_ to_person_", or "received _object_ from _person_". Also, things like "became friends with _person_" and "joined _group_" would be great to have. We could have "installed _activity_" and "updated _activity_" actions. Etc. Browse might reference any downloaded objects, in addition to it's session "instance". We can give activities the freedom to use this as they see fit. As seen here (http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#01), we might also distinguish between viewing and modifying objects. If I read a document without making edits to it, we could say as much, and that action would reference the same version of the same object as another action. >> This diagram represents the action of recording a roll of 10 photos of >> butterflies in an instance of a recording activity derived from a specified >> bundle. > > Is that an XO software bundle? > >> Key points: >> >> * I can paint on a photo but not on a record instance. >> >> * On the other hand, I can use the instance to >> >> a) resume recording butterflies or >> >> b) to locate an activity prot
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jun 29, 2009 at 7:32 PM, Michael Stone wrote: > > Gary C. Martin wrote: > >> I like the intent, but I don't think the "activity centric" view has >> concrete enough spec to consider implementing yet. > > I want to convince you that we actually have enough detail to make forward > progress with. > > To that end, I'm going to offer a bunch of text on how I think this display is > supposed to work. > > You should go through it to identify > > a) things that don't make sense > b) things that are disputed or where I'm obviously wrong > c) things that are insufficiently specified > > and we should try to fix those. > > Then we'll be ready to do another round of discussion and prototyping. > > Regards, > > Michael > > --- > > The best picture I've ever extracted from people on this subject looks like > this: > > Mental Picture of the Experience of Recording Butterflies > > > * - action > / \ > instance - / \ > \ / \ > *--/ /--*---* - object container > / | //\\\ > bundle | / | \\\ > / / | | \\ > prototype / | | | \ > * * * * * - objects > > > This diagram represents the action of recording a roll of 10 photos of > butterflies in an instance of a recording activity derived from a specified > bundle. > > Key points: > > * I can paint on a photo but not on a record instance. > > * On the other hand, I can use the instance to > > a) resume recording butterflies or > > b) to locate an activity prototype suitable for beginning a new > recording action on a different theme. > > (The instance functions a bit like a UI continuation.) > > --- > > Analyzing > > http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#02 > > we see that > > * Each top-level entry in the display depicts an "action". > > * Each top-level entry can be zoomed in or out (i.e. "contracted" or > "expanded", but as part of a large-scale zoom metaphor). > > When contracted, each entry displays a horizontal summary of the action > containing: > > 1) the past tense of a verb > 2) an "action resume display", consisting of > > a) an initiator-colored activity icon, > b) a bold label with the action title, and > c) a resume button > > 3) an optional iconic summary of the actions's participants, > > [Eben -- how do we abbreviate this summary if there were lots of > participants?] We show 3 "key" participants (these could be the first 3, or perhaps the 3 who participated the most, for some definition of "most"), and show the total number of participants as a little badge following them (as shown here: http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#03). Hovering over the number badge would reveal a palette listing all participants. > > 4) and a mandatory "freshness" indicator. > > [In Scott's journal2 work, we'd also have a tag cloud.] > > When expanded, we vertically concatenate the "brief summary" display described > above with a second "details view" that is inadequately fleshed out. > > In the single example suggested by Eben, this details view appears to consist > of: > > 5) a grid of cells, each containing Notably, this is a slightly simplified version of the proposed grid view of objects. Compare: http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#03 http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10 > 6) a star-shaped colored selector > > [Eben -- is this used for favoriting or for acting on object-sets?] The star is for marking items as favorites. > 7) a summary display, which, for images, displays the image object and its > title The intent here was to always show whatever the "preview" for that object might be. If there is no preview, we'd show a framed representation of the icon instead. > 8) some sort of arrow-labeled button This is the "details" button. One of these exists for each object, and reveals the details page for that object. From the details page it would be possible to edit, describe, tag, and act on the object. > [Eben -- I imagine that each of these buttons is supposed to represent > some sort of "act on with " button with both holes filled in, > per our prevoius discussion: > > > http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2#.22Act_on_with.22 > > Perhaps you could flesh this out a bit, but explaining the interaction > design you imagine for multi-object cross-action "act on ___ with ___"? Perhaps the "open" button should always reveal a list of compatible activities so that you can always "act on ___ with ___." Then, resuming an activity would always happen only when clicking on the action (resume as usual), or on
Re: [Sugar-devel] Journal feature request--more data in main display
Oh, Michael, you're in trouble now. ^_^ You risk reinventing the data-centric Ontology in an Object-Oriented Programming form. This is one of the worst sinks for time and mental energy that I know of. It saps the will, because soon users become obsessed with making the map match the territory, when in reality everybody wants to make different maps in different territories. Still, we have to do something along these lines. If we actually do it as OOP, not just in OOP, so that users can redefine the classes, we might get somewhere without turning our minds to stone. Maybe we can make it into a pattern language? On Mon, Jun 29, 2009 at 4:32 PM, Michael Stone wrote: > > Gary C. Martin wrote: > >> I like the intent, but I don't think the "activity centric" view has >> concrete enough spec to consider implementing yet. > > I want to convince you that we actually have enough detail to make forward > progress with. > > To that end, I'm going to offer a bunch of text on how I think this display is > supposed to work. > > You should go through it to identify > > a) things that don't make sense > b) things that are disputed or where I'm obviously wrong > c) things that are insufficiently specified > > and we should try to fix those. > > Then we'll be ready to do another round of discussion and prototyping. > > Regards, > > Michael > > --- > > The best picture I've ever extracted from people on this subject looks like > this: > > Mental Picture of the Experience of Recording Butterflies > > > * - action > / \ > instance - / \ > \ / \ > *--/ /--*---* - object container > / | //\\\ > bundle | / | \\\ > / / | | \\ > prototype / | | | \ > * * * * * - objects I'm with you on actions, object containers and objects, but I don't know what the instance arrow is pointing to, nor what bundles and prototypes would be here. Is a prototype a structure for a particular kind of collection, such as a portfolio outline? I would be interested to see this applied to a few dozen common workflows, such as student portfolios, a business plan, a lesson plan, a textbook incorporating software models, a research report, a photo album with pictures extracted from different sessions by different people, or downloaded from somewhere, and so on. If we knew what workflows our teachers and students needed, we would have a better chance of designing something that met their needs. > This diagram represents the action of recording a roll of 10 photos of > butterflies in an instance of a recording activity derived from a specified > bundle. Is that an XO software bundle? > Key points: > > * I can paint on a photo but not on a record instance. > > * On the other hand, I can use the instance to > > a) resume recording butterflies or > > b) to locate an activity prototype suitable for beginning a new > recording action on a different theme. > > (The instance functions a bit like a UI continuation.) The continuation for resuming, yes, with the prototype like a factory class, spawning instances as needed. > --- > > Analyzing > > http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#02 Aha! The object-oriented view is just what Tomeu and I were talking about, but better. Except that the sample screens don't have a place for tags. I vote for objects rather than actions, which I find to be too wordy and uninformative. I want titles of documents and other objects. Don't tell me how I made it, let me tell you what it's for, or about. I also want the object view so that I can apply any appropriate Activity to the object. I don't want it tied to the Activity used to create it. I should be able to write a program or a Web page in a text editor, and then run or open it. I should be able to save a PDF from any appropriate application, and then view or edit it in some other program. I should have an easy way to create graphic files, and then hand them over to some bundle structure as artwork for a program. And so on. OOP as Alan intended it. > we see that > > * Each top-level entry in the display depicts an "action". > > * Each top-level entry can be zoomed in or out (i.e. "contracted" or > "expanded", but as part of a large-scale zoom metaphor). > > When contracted, each entry displays a horizontal summary of the action > containing: > > 1) the past tense of a verb > 2) an "action resume display", consisting of > > a) an initiator-colored activity icon, > b) a bold label with the action title, and > c) a resume button > > 3) an optional iconic summary of the actions's participants, > > [Eben -- how do we abbreviate this summary if there were lots of > participant
Re: [Sugar-devel] Journal feature request--more data in main display
Gary C. Martin wrote: > I like the intent, but I don't think the "activity centric" view has > concrete enough spec to consider implementing yet. I want to convince you that we actually have enough detail to make forward progress with. To that end, I'm going to offer a bunch of text on how I think this display is supposed to work. You should go through it to identify a) things that don't make sense b) things that are disputed or where I'm obviously wrong c) things that are insufficiently specified and we should try to fix those. Then we'll be ready to do another round of discussion and prototyping. Regards, Michael --- The best picture I've ever extracted from people on this subject looks like this: Mental Picture of the Experience of Recording Butterflies * - action / \ instance - / \ \ / \ *--/ /--*---* - object container /| //\\\ bundle |/ | \\\ / / | | \\ prototype / | | | \ ** * * *- objects This diagram represents the action of recording a roll of 10 photos of butterflies in an instance of a recording activity derived from a specified bundle. Key points: * I can paint on a photo but not on a record instance. * On the other hand, I can use the instance to a) resume recording butterflies or b) to locate an activity prototype suitable for beginning a new recording action on a different theme. (The instance functions a bit like a UI continuation.) --- Analyzing http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#02 we see that * Each top-level entry in the display depicts an "action". * Each top-level entry can be zoomed in or out (i.e. "contracted" or "expanded", but as part of a large-scale zoom metaphor). When contracted, each entry displays a horizontal summary of the action containing: 1) the past tense of a verb 2) an "action resume display", consisting of a) an initiator-colored activity icon, b) a bold label with the action title, and c) a resume button 3) an optional iconic summary of the actions's participants, [Eben -- how do we abbreviate this summary if there were lots of participants?] 4) and a mandatory "freshness" indicator. [In Scott's journal2 work, we'd also have a tag cloud.] When expanded, we vertically concatenate the "brief summary" display described above with a second "details view" that is inadequately fleshed out. In the single example suggested by Eben, this details view appears to consist of: 5) a grid of cells, each containing 6) a star-shaped colored selector [Eben -- is this used for favoriting or for acting on object-sets?] 7) a summary display, which, for images, displays the image object and its title 8) some sort of arrow-labeled button [Eben -- I imagine that each of these buttons is supposed to represent some sort of "act on with " button with both holes filled in, per our prevoius discussion: http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2#.22Act_on_with.22 Perhaps you could flesh this out a bit, but explaining the interaction design you imagine for multi-object cross-action "act on ___ with ___"? Also, could you think about giving it a different icon from the "resume" icon?] > The still raises lot's of questions, what happens when you resume some > image you painted from way back to take a quick look? We need to be more specific. You can either 1) resume the /action/ containing that image, or you can 2) incorporate the image into a new action, (i.e. acting on the image with some selected activity+mode) You tell Sugar that you want case (1) by clicking the resume button [or the activity icon?] in the "activity resume display" that I described above. Eben hasn't spelled it out, but I imagine that you indicate case (2) by one of: a) selecting the object and clicking the "add new entry" button in the Journal, which presumably prompts you, at some point, for an activity+mode with which to act on your objects b) copy-pasting a set of selected objects into a running instance or into a selected action c) dragging a set of selected objects object into an action or an instance icon d) selecting an activity+mode as a "current tool" [think of Photoshop] with which to process a sequence of objects that you're about to indicate [By "activity+mode", I'm referring to issues like "do you want this activity to display the object, a summary of the object, the object's source code, its own self-test results, e
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jun 29, 2009 at 7:01 AM, Tomeu Vizoso wrote: > On Sun, Jun 28, 2009 at 20:13, Gary C Martin wrote: >> Hi Tomeu, >> >> On 28 Jun 2009, at 09:59, Tomeu Vizoso wrote: >> >>> 2009/6/21 Edward Cherlin : We have about 60 characters worth of blank space in every Journal entry. It would be a great help if we could display 40-50 characters from the description field for each entry on the main page. We could also drop off the word Activity from every Activity name. >>> >>> Are you sure that the description is the best use of the available >>> space? I was thinking about displaying the tags beneath the title >>> >>> Would that work for you? >> >> +1 for tags beneath titles. >> >> I've just tried a quick mock-up to bounce around some ideas, Tomeu is there >> a wiki page you're working from that this (and others) could go? Likely >> needs more refinement but might a few more thinking on it :-) > > I'm afraid that would be quite a bit of work, right now I'm planning > on just adding there the string as-they-are from the Tags field. An excellent start, particularly if we can get the beginning of the string-as-it-is from the Description field. > But would be great if someone wanted to work further on tag entry and display. > > Regards, > > Tomeu > >> Regards, >> --Gary >> >> >> >> >> >> >> > -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://earthtreasury.org/worknet (Edward Mokurai Cherlin) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 29 Jun 2009, at 16:07, Tomeu Vizoso wrote: > On Mon, Jun 29, 2009 at 16:55, Aleksey Lim > wrote: >> On Sun, Jun 21, 2009 at 02:39:22PM -0700, Edward Cherlin wrote: >>> We have about 60 characters worth of blank space in every Journal >>> entry. It would be a great help if we could display 40-50 characters >>> from the description field for each entry on the main page. We could >>> also drop off the word Activity from every Activity name. >> >> maybe using several views >> * one line view >> * full view(multi lined view) >> * thumbs >> >> btw I hope we'll decide to work on all these object list related >> features in one place, now we have Journal, Library(partially >> implemented) >> and not implemented Dairy(http://erikos.sweettimez.de/?p=742) > > Yup, I personally love the mockups at > http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal . > > Other opinions? I like the intent, but I don't think the "activity centric" view has concrete enough spec to consider implementing yet. There is just way too much magic sauce in those mock-ups to my mind. The closest I've seen something like this implemented, is with Apple's iPhoto, where imported photos are auto arranged into single expandable "events" based on each photos date/time metadata. You're given a couple of preferences for adjusting the granularity (one event per week, one event per day, one event per 8hrs, one event per 2hrs). Works quite well most of the time, you can always manually merge two events into one, or split one event into two, if it gets them wrong. I guess we could make the "activity centric" view work in the same way, a fixed time slice that rolls up N hrs work into a collapsable/ expandable block that the user can custom name (and/or some auto name based on the content). The still raises lot's of questions, what happens when you resume some image you painted from way back to take a quick look? Where does it now show in activity centric view? Does it get removed from its old block positioning and to some new active block; perhaps it get multi- linked so now appears twice (you can still find it in the original old place and also find it in new place)? -=-=-=-=-=- The grid/thumb view should be a top level button, not as is shown buried in a sub palette here: http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#09 I'd consider 2 primary view type buttons: 1). List view, just as we get now 2). Grid view, much like as implemented in Library -=-=-=-=-=- Having said all this, it seems sensible to pick a few solid Journal improvements and just make some robust steps forward, like: - Showing tags under the title would be great (Tomeu, I will help where I can) - Batch entry modification (FWIW, don't like the tick box, that feels like an old school html web form hack) - Better Anything toolbar filter palette (use a grid layout to minimise scrolling) - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 29 Jun 2009, at 15:55, Aleksey Lim wrote: > On Sun, Jun 21, 2009 at 02:39:22PM -0700, Edward Cherlin wrote: >> We have about 60 characters worth of blank space in every Journal >> entry. It would be a great help if we could display 40-50 characters >> from the description field for each entry on the main page. We could >> also drop off the word Activity from every Activity name. > > maybe using several views > * one line view > * full view(multi lined view) > * thumbs > > btw I hope we'll decide to work on all these object list related > features in one place, now we have Journal, Library(partially > implemented) > and not implemented Dairy(http://erikos.sweettimez.de/?p=742) I was hoping we could cherry pick some features being tested else where, and migrate into the single Journal, e.g. your Library demonstrates grid view is very useful and implementable. Actually, I wish you'd just started hacking on a branch of the actual Journal from the start :-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jun 29, 2009 at 16:55, Aleksey Lim wrote: > On Sun, Jun 21, 2009 at 02:39:22PM -0700, Edward Cherlin wrote: >> We have about 60 characters worth of blank space in every Journal >> entry. It would be a great help if we could display 40-50 characters >> from the description field for each entry on the main page. We could >> also drop off the word Activity from every Activity name. > > maybe using several views > * one line view > * full view(multi lined view) > * thumbs > > btw I hope we'll decide to work on all these object list related > features in one place, now we have Journal, Library(partially implemented) > and not implemented Dairy(http://erikos.sweettimez.de/?p=742) Yup, I personally love the mockups at http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal . Other opinions? Regards, Tomeu > -- > Aleksey > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sun, Jun 21, 2009 at 02:39:22PM -0700, Edward Cherlin wrote: > We have about 60 characters worth of blank space in every Journal > entry. It would be a great help if we could display 40-50 characters > from the description field for each entry on the main page. We could > also drop off the word Activity from every Activity name. maybe using several views * one line view * full view(multi lined view) * thumbs btw I hope we'll decide to work on all these object list related features in one place, now we have Journal, Library(partially implemented) and not implemented Dairy(http://erikos.sweettimez.de/?p=742) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sun, Jun 28, 2009 at 20:13, Gary C Martin wrote: > Hi Tomeu, > > On 28 Jun 2009, at 09:59, Tomeu Vizoso wrote: > >> 2009/6/21 Edward Cherlin : >>> >>> We have about 60 characters worth of blank space in every Journal >>> entry. It would be a great help if we could display 40-50 characters >>> from the description field for each entry on the main page. We could >>> also drop off the word Activity from every Activity name. >> >> Are you sure that the description is the best use of the available >> space? I was thinking about displaying the tags beneath the title >> >> Would that work for you? > > +1 for tags beneath titles. > > I've just tried a quick mock-up to bounce around some ideas, Tomeu is there > a wiki page you're working from that this (and others) could go? Likely > needs more refinement but might a few more thinking on it :-) I'm afraid that would be quite a bit of work, right now I'm planning on just adding there the string as-they-are from the Tags field. But would be great if someone wanted to work further on tag entry and display. Regards, Tomeu > Regards, > --Gary > > > > > > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sun, Jun 28, 2009 at 3:20 PM, Gary C Martin wrote: ... FWIW: That transcluded wiki template set-up was kind'a hard for me to get my > head around, took some poking before I managed to edit the right sub page > correctly. Not that there are likely many wiki novices expected to edit > these techy pages, but just thought I'd mention the complexity of making a > basic edit here. > I agree! It was an experiment and exercise, which I'll end soon. (I've added some hints in the interim.) I wanted to get the table of contents navigator and maybe show some thumbnails, but that would require wrapping each of the header lines (==, ===, etc.) on each subpage in tags, but they are entered by the author. Perhaps there is a wiki extension that would pre-process the subpages for that purpose (but I haven't really looked for it yet.) The bare bones alternative is just the Special:PrefixIndex/ subpages block, but that is pretty bare by itself. Thanks for the feedback! --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
Hi Fred, On 28 Jun 2009, at 19:33, Frederick Grose wrote: > On Sun, Jun 28, 2009 at 2:13 PM, Gary C Martin > wrote: > > I've just tried a quick mock-up to bounce around some ideas, Tomeu > is there a wiki page you're working from that this (and others) > could go? Likely needs more refinement but might a few more thinking > on it :-) > > http://wiki.sugarlabs.org/go/Design_Team/Proposals#Journal would be > available. Thanks, it's updates with some extra text description as well. Regards, --Gary FWIW: That transcluded wiki template set-up was kind'a hard for me to get my head around, took some poking before I managed to edit the right sub page correctly. Not that there are likely many wiki novices expected to edit these techy pages, but just thought I'd mention the complexity of making a basic edit here. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sun, Jun 28, 2009 at 2:13 PM, Gary C Martin wrote: > Hi Tomeu, > > On 28 Jun 2009, at 09:59, Tomeu Vizoso wrote: > >> 2009/6/21 Edward Cherlin : >>> >>> We have about 60 characters worth of blank space in every Journal >>> entry. It would be a great help if we could display 40-50 characters >>> from the description field for each entry on the main page. We could >>> also drop off the word Activity from every Activity name. >> >> Are you sure that the description is the best use of the available >> space? I was thinking about displaying the tags beneath the title >> >> Would that work for you? > > +1 for tags beneath titles. > > I've just tried a quick mock-up to bounce around some ideas, Tomeu is there > a wiki page you're working from that this (and others) could go? Likely > needs more refinement but might a few more thinking on it :-) nice. > Regards, > --Gary > > > > > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sun, Jun 28, 2009 at 2:13 PM, Gary C Martin wrote: > > I've just tried a quick mock-up to bounce around some ideas, Tomeu is there > a wiki page you're working from that this (and others) could go? Likely > needs more refinement but might a few more thinking on it :-) http://wiki.sugarlabs.org/go/Design_Team/Proposals#Journal would be available. --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sun, Jun 21, 2009 at 5:39 PM, Edward Cherlin wrote: > We have about 60 characters worth of blank space in every Journal > entry. It would be a great help if we could display 40-50 characters > from the description field for each entry on the main page. We could > also drop off the word Activity from every Activity name. I think the blank space you're referring to is reserved to show collaboration, so it's not strictly wasted space. It might be worth comparing the current implementation to the mockups here: http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal In particular, look at slides 2 and 3. I'd be happy to hear feedback on how to improve those designs. I think dropping "Activity" from the default instance names is a fine idea. In fact, I'm still hoping that we can institute a policy that allows activities to specify their own defaults, so that instead of getting "Paint Activity" I could instead get "Eben's Painting." I think exploring the exposure of tags in the list view (by making the title portion two lines, with the tags beneath the title) is worth exploring. Getting the tagging system out in the open would be really beneficial, I think. Eben > I am going to create dozens of lesson plans in Turtle Art soon, and I > would like not to have to fish for them. The search field helps, but > is not enough. Eventually, we will have hundreds and perhaps thousands > of Turtle Art lessons, and likewise for Etoys, Scratch, Pippy, and a > number of other activities. > > -- > Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name > And Children are my nation. > The Cosmos is my dwelling place, The Truth my destination. > http://earthtreasury.org/worknet (Edward Mokurai Cherlin) > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
2009/6/21 Edward Cherlin : > We have about 60 characters worth of blank space in every Journal > entry. It would be a great help if we could display 40-50 characters > from the description field for each entry on the main page. We could > also drop off the word Activity from every Activity name. Are you sure that the description is the best use of the available space? I was thinking about displaying the tags beneath the title Would that work for you? Regards, Tomeu > I am going to create dozens of lesson plans in Turtle Art soon, and I > would like not to have to fish for them. The search field helps, but > is not enough. Eventually, we will have hundreds and perhaps thousands > of Turtle Art lessons, and likewise for Etoys, Scratch, Pippy, and a > number of other activities. > > -- > Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name > And Children are my nation. > The Cosmos is my dwelling place, The Truth my destination. > http://earthtreasury.org/worknet (Edward Mokurai Cherlin) > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Journal feature request--more data in main display
We have about 60 characters worth of blank space in every Journal entry. It would be a great help if we could display 40-50 characters from the description field for each entry on the main page. We could also drop off the word Activity from every Activity name. I am going to create dozens of lesson plans in Turtle Art soon, and I would like not to have to fish for them. The search field helps, but is not enough. Eventually, we will have hundreds and perhaps thousands of Turtle Art lessons, and likewise for Etoys, Scratch, Pippy, and a number of other activities. -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://earthtreasury.org/worknet (Edward Mokurai Cherlin) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
