Time |
Nick |
Message |
09:11 |
cms |
excellent |
09:11 |
|
first of all, thanks for meeting |
09:11 |
|
it's been a while since we have had the chance to discuss the UI design |
09:12 |
|
in the meantime, i have a copy of SoaS that allowed me to test the latest release |
09:12 |
|
and i was blown away--it works amazingly well |
09:12 |
|
and i'm referring in particular to the new home view |
09:12 |
tomeu |
cms: in what aspects it exceeded your expectatives? |
09:12 |
|
aha |
09:13 |
|
and next release we may have versions in the journal ;) |
09:13 |
cms |
well, it is essentially the complete manifestation of the design |
09:13 |
|
for home |
09:13 |
|
and it proved to me that we were on the right track |
09:14 |
|
i had reservations about Home last time we talked, that were largely founded in having only had access to a previous version of Sugar without a complete Home implementation |
09:14 |
tomeu |
I'm a bit sad we didn't had time to do the alt version of the home, when you go back to all new instances while alt is pressed |
09:14 |
cms |
i no longer have any reservations--only ideas for how we can continue to extend it |
09:14 |
|
tomeu: yes, i agree that would be a nice feature to add |
09:14 |
eben |
tomeu: That's a great extension to add. |
09:14 |
tomeu |
it will fall for 0.86 for sure |
09:14 |
eben |
excellent |
09:15 |
cms |
like the alt version, there are ways that we can continue to improve and extend Home |
09:15 |
garycmartin |
tomeu: fab |
09:15 |
cms |
for instance, walter mentioned the ability to have groups of activities |
09:15 |
|
i think that would be a great way to extend the concept of favorites |
09:15 |
|
i.e., instead of just one set of favorites, could i assign other categories to my activities? |
09:15 |
eben |
cms: Right: I think that activity grouping might actually be best realized with the search that's been implied, but missing, so far. |
09:16 |
tomeu |
there's tagging, as well |
09:16 |
cms |
eben: yes, that would be a way to do it. i also think that you could perhaps assign categories to activities on the basis of tags, similar to in the journal |
09:16 |
eben |
Grouping is then synonymous with tagging (which we already support via the Journal), and the view would behave just like the other views, eg. neighborhood. |
09:16 |
tomeu |
and yeah, being able to start typing to select the activity you want to launch would be great |
09:16 |
cms |
eben: exactly |
09:17 |
|
so i think we have a great foundation upon which to keep improving |
09:17 |
garycmartin |
eben: yes getting search right could solve groupings without adding complications to the basic ui |
09:17 |
eben |
I think the other important feature, in addition to building the search field, is to add tags into activity.info so that activities can come "pre-tagged". |
09:17 |
cms |
eben: that's a great idea |
09:17 |
|
it would be nice to have predefined sets of categories |
09:18 |
eben |
This can make it easier to jump in and find "games", or "music" or "programming" activities, and can also serve for developers to group sets like "mamamedia" and "gcompris" |
09:18 |
|
Which was a big feature request from those groups early on. |
09:18 |
cms |
before we go too far brainstorming new features (which we generally should!), i wanted to put out an agenda for this morning |
09:18 |
garycmartin |
cms: predefined set of categories, always a major nightmare of ontology... |
09:19 |
|
cms: we still can't agree on ASLO |
09:19 |
cms |
gary: good point! |
09:19 |
eben |
cms: I'm not sure it's necessary to predefine them. I think instead it would be nice to track them so that organically the sets emerge. |
09:19 |
cms |
eben: yes, that probably makes more sense |
09:20 |
eben |
There's no reason an activity couldn't use any tag at all, but clearly there is some advantage to having the "basic" tags which other activities agree on. |
09:20 |
tomeu |
garycmartin: more than string disagreement, I see indiference |
09:20 |
|
garycmartin: so if someone motivated wanted to go ahead... |
09:20 |
garycmartin |
tomeu: ahh |
09:20 |
cms |
so, briefly, for our agenda: |
09:21 |
|
(1) i thought we should talk about any plans we have for testing the UI. i know that some of this has already happened, maybe tomeu can fill us in? |
09:21 |
|
(2) we should discuss the development schedule and any features that need design work |
09:22 |
|
(3) for our next meeting, we should reconvene and look at concrete design ideas (in form of storyboards). let's agree on what we should work on today |
09:22 |
|
does anyone want to add anything? |
09:23 |
garycmartin |
cms: sounds good. |
09:23 |
eben |
(2) and (3) are pretty broad, so we'll probably cover most topics people are interested in under those. |
09:23 |
cms |
i thought it would be a relatively short meeting today--more of a planning conversation |
09:23 |
|
eben: that's true. we should make an attempt to prioritize |
09:23 |
|
hi walter! |
09:23 |
tomeu |
don't know about testing, but walterbender would know |
09:24 |
|
(03:20:51 PM) cms: (1) i thought we should talk about any plans we have for testing the UI. i know that some of this has already happened, maybe tomeu can fill us in? |
09:24 |
walterbender |
hi. sorry I am late |
09:24 |
tomeu |
hi walterbender and sdziallas |
09:24 |
sdziallas |
hi all :) |
09:24 |
cms |
hi sdziallas |
09:24 |
garycmartin |
sdziallas: hi |
09:24 |
|
walterbender: morning! |
09:24 |
cms |
walter and sdziallas, are you able to read the transcript? |
09:25 |
walterbender |
cms: alas, no |
09:25 |
cms |
or should i quickly sum up where we are? |
09:25 |
walterbender |
please |
09:25 |
tomeu |
I can quickly paste it |
09:25 |
sdziallas |
yeah, would be great! |
09:25 |
cms |
great, thanks tomeu |
09:25 |
tomeu |
sdziallas, walterbender: http://pastebin.be/17936 |
09:25 |
sdziallas |
tomeu: thanks! |
09:26 |
tomeu |
yw |
09:28 |
walterbender |
is all caught up |
09:28 |
|
cms: how would you like to proceed? |
09:29 |
cms |
i thought we could talk about any testing that happened |
09:29 |
|
whether there were any observations that we should take into account |
09:29 |
walterbender |
cms: I am unaware of any testing in the CHI sense |
09:29 |
cms |
ok |
09:29 |
walterbender |
cms: but we have plenty of observations from the field |
09:30 |
|
even yesterday, we saw 30-40 kids use the interface for the first time |
09:30 |
cms |
walterbender: are those observations listed anywhere? |
09:30 |
walterbender |
cms: not in one single place |
09:31 |
|
cms: but for example, Caroline is writing up notes from yesterday that confrim many of our own observations... |
09:31 |
cms |
walterbender: excellent! |
09:31 |
walterbender |
I can paste her rough notes if you'd like |
09:31 |
cms |
i think it's important to continue to observe how kids are using the UI and the home view, in order to continue to improve it |
09:31 |
tomeu |
wow, that's great |
09:31 |
cms |
walterbender: sure, that would be great. though i wonder if we might look at those independently after the meeting |
09:32 |
|
unless there are specific observations that could inform our discussion today? |
09:32 |
walterbender |
http://pastebin.be/17938 |
09:33 |
cms |
great, thanks! |
09:33 |
|
generally, what i wanted to accomplish today was to create a list of features that need designing |
09:33 |
|
in light of our development timeline |
09:33 |
walterbender |
cms: I think these observations confirm issues we ahve discussed about the home page and some issues we discussed about SoaS |
09:33 |
|
discoverability |
09:33 |
cms |
interesting, yes |
09:34 |
|
not being able to go back to home |
09:34 |
walterbender |
my take away is slightly different from Caroline's |
09:34 |
cms |
are kids using the frame? |
09:34 |
walterbender |
Not in a 30-60 minute session... |
09:34 |
cms |
it takes more time to discover perhaps |
09:35 |
walterbender |
cms but in more regular use, yes |
09:35 |
cms |
the home issue is interesting |
09:35 |
|
the XO of course had keys for the four zoom-levels |
09:35 |
walterbender |
cms: that is one of the problems with user studies... |
09:35 |
eben |
walterbender: I'm curious, it says the kids aren't using the frame, but it also says they start lots of activities without closing any. |
09:35 |
|
Those two statements seem to be in conflict. |
09:35 |
walterbender |
cms: in a 30-60 minute session, the views aren't used at all |
09:36 |
|
eben: they had an adult helping them |
09:36 |
cms |
walterbender: kids appear to remain in the activities they start, and switch between them |
09:36 |
walterbender |
eben: part of the problem was no OLPC keyboard |
09:37 |
cms |
walterbender: the frame is the parallel way to navigate to the other zoom-levels; |
09:37 |
garycmartin |
I wish we had a toolbar design where 'Stop' was always visible. |
09:37 |
eben |
walterbender: Right, but we can't depend on that, in any case. But ok, Frame takes some getting used to. |
09:37 |
walterbender |
garycmartin: yes. I think that is a priority |
09:37 |
|
one of my take aways from yesterday is that the kids don't grok tabs |
09:37 |
eben |
garycmartin: Yes, that's a tricky issue. The new toolbar design Could actually provide that, maybe. |
09:38 |
cms |
how do kids use sugar at first? are they left to their own devices, or do they get a brief tutorial? |
09:38 |
eben |
walterbender: That's understandable. Do you think the new design might improve that? |
09:38 |
walterbender |
cms: in yesterday's test, it was sink or swim... no time (or patience) for a tutorial |
09:39 |
|
cms: we cannot count on one |
09:39 |
cms |
walterbender: and we shouldn't need one ;) |
09:39 |
walterbender |
eben: think a design where tabs look more like buttons (like the new design) will probably help |
09:39 |
eben |
Also, the other non-activity-specific comment in these notes is about the keep dialog being annoying, but I suspect that's true in these cases because they are short sessions in which all of the activities are started from scratch, and not meant to be kept permanently, so I think it might be less a problem in practice. |
09:40 |
walterbender |
cms: I think teachers/mentors would look at a manual/tutorial |
09:40 |
|
cms: but we can do a better job of "staging" |
09:40 |
eben |
walterbender: Right. I think it may also help since the tabs don't remove the default toolbar...they appear beneath it, so you never get lost. |
09:40 |
cms |
eben: i think the new toolbars are a huge improvement |
09:41 |
|
how would we go about laying the groundwork for their adoption? |
09:42 |
walterbender |
here is an idealet: maybe the frame and journal should appear on the default toolbar |
09:42 |
eben |
I think we just need to develop them in parallel...make it easy for devs to try them out. |
09:43 |
cms |
walterbender: that is a good idea |
09:43 |
eben |
walterbender: Hmmm, not sure. It makes them available, though they aren't actually part of the activity... |
09:43 |
cms |
walterbender: certainly the frame makes sense there |
09:43 |
|
eben: i do think we need to make the frame more discoverable... |
09:44 |
eben |
cms: Yes, true. |
09:44 |
cms |
what if we went back to activating the screen edges to invoke the frame? |
09:44 |
eben |
Oh, that's been turned off? |
09:44 |
|
That's the only way it's discoverable at all... |
09:44 |
cms |
the corners currently, correct? |
09:44 |
garycmartin |
eben: only by default, the pref is still there |
09:44 |
eben |
We definitely can't depend on an unlabeled key on the keyboard. |
09:44 |
cms |
i meant the entire edge of the screen, on delay |
09:44 |
eben |
garycmartin: I think it's a big mistake to turn it off by default. |
09:45 |
|
My feeling is that we should set a delay by default, so accidental invocation is less likely. They may then turn it off once they've discovered it and understand how to use it. |
09:46 |
|
cms: I think the corners are still sufficient, actually. |
09:46 |
cms |
eben: +1 |
09:46 |
walterbender |
On SoaS, I think we may want to turn edges back pn |
09:46 |
garycmartin |
eben: lets make sure we hide the cursor on keyboard use then. cursor is quite large and get's in the way when writing, flinging it out the way is going to invoke edges |
09:46 |
eben |
garycmartin: Yes, definitely. |
09:46 |
cms |
walterbender: yes, i think the edges would make it more discoverable. it was an issue on the XO due to the trackpad, but on other systems it would probably work fine |
09:46 |
eben |
I think there's been a bug filed on that issue for a long time. |
09:47 |
walterbender |
Sugar really is different on different machines... |
09:47 |
garycmartin |
eben: FWIW I tried hot edges for a week and eventually switched it off. Too many accidental invocations. |
09:47 |
eben |
Actually, I still disagree with edges, myself. I think that we should keep them clear so that scrolling, and hitting toolbar buttons, doesn't interfere with it... |
09:47 |
|
I think corners alone would be fine on a short delay, and enough to make it discoverable at least. |
09:47 |
cms |
garycmartin: could edges only be turned on by default? if it becomes too distracting, it should be easy to turn off, but initially we want to make sure people are able to find the frame |
09:48 |
walterbender |
eben: maybe bigger corners? |
09:48 |
eben |
cms: You don't think corners will be enough? |
09:48 |
cms |
eben: i'm not convinced the corners are discoverable enough |
09:48 |
|
walterbender: bigger corners might do the trick |
09:48 |
walterbender |
without a frame key, it is hard to discover |
09:48 |
|
or put it on the default menu |
09:48 |
eben |
cms: Maybe we should test it. We didn't even have edge activation at all for months and people were complaining that the Frame was activated too easily, recall. |
09:48 |
cms |
eben: that's true. although we were testing on XOs |
09:49 |
walterbender |
eben: but we should make sure wr do more testing on nonXOs |
09:49 |
cms |
eben: ultimately, it seems like it really is a preference, but we should set the default in favor of easy discoverability |
09:49 |
eben |
Maybe its something we need to test out. Set it up 3 or 4 ways: corner-no-delay, corner-delay, corner-edge-delay, corner-edge-long-delay... |
09:50 |
|
cms: Yeah, definitely. I agree it needs to be discoverable; but maybe we should test to see what level is discoverable, and what level is annoying. |
09:50 |
cms |
let's go back to toolbars for a minute |
09:50 |
|
is there any additional design work that needs to happen, for instance adding the frame icon? |
09:51 |
|
tomeu, would it be possible to start developing the new toolbars for core activities for the next release? |
09:51 |
eben |
cms: Hmm.....I suppose you could "special case" the Frame button, if we decided it did have a place in the toolbar... |
09:51 |
|
It could actually sit in the very corner position. |
09:51 |
cms |
eben: yes, i rather like the idea... |
09:51 |
garycmartin |
eben: toolbar, adding the stop buttong, to mock-ups don't show it, think sharing is missing too IIR ;-) |
09:51 |
eben |
And not take up addition space. |
09:51 |
cms |
eben: right! |
09:51 |
eben |
We also had another concept for the Frame button, which I kind of like still, too. |
09:52 |
cms |
eben: which concept was that? |
09:52 |
eben |
That was: Any time the cursor enters the 75x75px square in any corner of the screen, we reveal a Frame button in it's place. |
09:52 |
walterbender |
eben: please remind us |
09:53 |
|
eben: that certainly would help on the XO, where there is a corresponding Frame button |
09:53 |
|
but on a standard keyboard, I don't know |
09:53 |
cms |
eben: an interesting idea, though i think a fixed position on the toolbar may ultimately be more effective |
09:53 |
garycmartin |
eben: yea I like it, bigger corners (click to show frame) or hit the very corner for auto reveal. |
09:54 |
eben |
walterbender: It should help on any machine...because the button could appear instantaneously... |
09:54 |
cms |
eben: the frame "button" could be slightly grayed out and only in the top left |
09:55 |
eben |
cms: Yes, that might also work. |
09:55 |
cms |
eben: the advantage of the hover is that it could happen for all four corners... |
09:55 |
eben |
cms: Right, which is an important idea. |
09:55 |
|
The gray button in the corner of the toolbar is neatly minimal, though... |
09:55 |
|
I guess it could be in both corners, but that doesn't buy you that much. |
09:56 |
cms |
eben: yes, it could feel very integrated |
09:56 |
walterbender |
or both |
09:56 |
eben |
walterbender: Right, that's what I was suggesting. |
09:56 |
cms |
walterbender: both corners? |
09:56 |
eben |
cms: We have two corners in every toolbar... |
09:56 |
cms |
walterbender: that could work... |
09:56 |
|
eben: true |
09:57 |
eben |
Not sure it's any better to have 2 instead of 1, when really it's all 4 that matter. |
09:57 |
|
If you don't have all 4, maybe one is enough? |
09:57 |
cms |
ok, let's make this into a task |
09:57 |
|
#1: design mockups to make the frame more discoverable |
09:58 |
eben |
#2: design mockups to polish the new toolbars |
09:58 |
cms |
i would like to record design "tasks" as we go a long and distribute the work at the end of our meeting, so we can reconvene next time and have something to look at |
09:58 |
|
thanks eben! |
09:59 |
|
is tomeu stil there? |
09:59 |
walterbender |
can we talk about about the homeview? |
09:59 |
eben |
In particular, there was some concern that the current toolbars don't have textual labels corresponding to them. That's the only big hole in their design, I think. |
09:59 |
garycmartin |
eben: yep |
09:59 |
cms |
eben: i don't think that is a problem--text would appear on rollover, consistent with the rest of the UI |
09:59 |
eben |
cms: That's not true.... |
09:59 |
|
On rollover, the full toolbar appears. ;) |
09:59 |
cms |
eben: no? |
09:59 |
|
eben: ah, yes |
10:00 |
|
eben: so i agree--we need a way to label toolbars |
10:00 |
eben |
Which, we argued, was better than text, since you could see our options in front of you...but that doesn't help in the case of documentation, or talking about them. |
10:00 |
cms |
should we move on to homeview? |
10:00 |
tomeu |
cms: back |
10:00 |
cms |
hi tomeu |
10:01 |
tomeu |
one problem I see with the new toolbars is that they don't belong to the set of widgets in gtk |
10:01 |
cms |
did you follow the conversation? we were just talking about the new toolbar design |
10:01 |
eben |
Yes, let's |
10:01 |
tomeu |
that means it will be quite a bit of work |
10:01 |
cms |
tomeu: i see |
10:01 |
tomeu |
palettes have been a nightmare to date |
10:01 |
eben |
tomeu: Right. They're more of an extension of palettes, which embed a toolbar within a palette... |
10:02 |
|
tomeu: True, but they finally work! |
10:02 |
tomeu |
yeah, and the current palettes don't do everything in the design |
10:02 |
cms |
tomeu: so we may need to prioritize |
10:02 |
tomeu |
eben: well, but when we move forward to the design, will break again ;) |
10:02 |
eben |
I'm not sure how else we're going to improve things, though. If we never try to build them, they'll never get built. :) |
10:03 |
cms |
tomeu: we should probably follow up with a technical feasibility discussion |
10:03 |
eben |
Yeah. |
10:03 |
tomeu |
I like the design btw, maybe would be worth one first exploratory try |
10:03 |
|
then reevaluate |
10:03 |
cms |
tomeu: that sounds like a great idea. we could also modify the design if there are major technical difficulities |
10:03 |
tomeu |
yeah, we should get our feet wet first |
10:03 |
eben |
A first implementation might not do all the nifty preview stuff, perhaps....though I think that could be enormously useful. |
10:04 |
tomeu |
nifty preview stuff? /me get scared |
10:04 |
eben |
A simple on/off toggle via button might be a good first step. |
10:04 |
|
tomeu: Making the toolbars appear transiently on hover, like palettes, so that you don't have to lock them into place to use sub-buttons... |
10:04 |
cms |
walterbender: we had started to talk earlier about home view, and enabling tagging/search for grouping activities |
10:04 |
eben |
But I digress....we can move on to Home. |
10:04 |
tomeu |
oh, I see |
10:05 |
|
will be easier without it, yeah |
10:05 |
walterbender |
re homeview, I have observed and gotten from teachers is the desire for more rather than less structure in the homeview |
10:05 |
cms |
walterbender: btw, i am fully on-board with ring now, after finally having had the chance to use the latest version |
10:06 |
|
when teachers said more structure, what did they mean by that? |
10:06 |
eben |
walterbender: Right. We propose to push the tagging idea further so that it's possible to create arbitrary groups of activities oneself, and also allow activity creators to pre-tag activities; the search field would then work just like neighborhood, and provide a way to filter the ring to specific activity sets/groups/tags |
10:06 |
walterbender |
I think some of the ideas discussed at the start of the meeting... easy to manage groups of actviites |
10:06 |
|
eben I think this would be a big help to teachers and for more casual use of Sugar |
10:07 |
cms |
yes, let's put some thought into that. eben, i like where search/tagging is going |
10:07 |
garycmartin |
Should activity managment be moved to Journal, rather than in a home list view? |
10:07 |
eben |
A parallel project to getting this searching working in Home, is to improve tagging in general so that it's easier and more fun to use. |
10:07 |
cms |
we could display tags next to search in the Home toolbar |
10:08 |
eben |
garycmartin: If we put *every* activity in the Journal (including pre-installed), we might do that. But I think the list view itself should remain |
10:08 |
cms |
garycmartin: actually, we talked about the implications of that earlier. i personally think there is merit to keeping them separate, for usability |
10:08 |
|
the journal feels too distant from home, even though structurally i tend to agree that activities could live there |
10:08 |
eben |
A thought to improve activity tagging: could we have the tag field exposed in the secondary palette, so that you can just right-click or hover and then add a tag? |
10:09 |
garycmartin |
eben: Isn't the current list view really just a custom filter of the Journal bundles (if all activities are added as bundles)? |
10:09 |
eben |
cms: Activities *should* live there....the Home view, ideally, should be a filter of the Journal, in a sense. |
10:09 |
tomeu |
garycmartin: I think that the idea is that all the zoom levels have their own list view, btw |
10:09 |
cms |
eben: that makes sense structurally, though it may not be important that it is visible in that way to the user |
10:09 |
eben |
garycmartin: That's the intent. I think that it might not be exact, if activities come preinstalled.... |
10:10 |
garycmartin |
eben: (so I guess I'm suggesting Journal has a nice button for filter activity bundles) |
10:10 |
cms |
tomeu: that's correct |
10:10 |
eben |
cms: ? |
10:10 |
|
Oh, right. |
10:10 |
cms |
eben: mean to say, i think we still need list view in home |
10:10 |
eben |
I'm agreeing with you. :) |
10:10 |
|
Just arguing that we might not need eg. "delete" in the list... |
10:11 |
walterbender |
a slightly orthogonal issue is whatever the default ordering is for the views (list or otherwise) |
10:11 |
cms |
well, |
10:11 |
eben |
maybe we could push management into the Journal "where it belongs" and make home all about launching. |
10:11 |
cms |
at that point it probably makes more sense to have all activity management happen in one place (i.e. home view) |
10:11 |
walterbender |
right now, it is based on modification date in the HomeView and Journal |
10:11 |
|
but people find that confusing |
10:11 |
eben |
walterbender: It would help if we had the list control.... |
10:12 |
walterbender |
something more stable over time, even alphabetical would be better by default |
10:12 |
eben |
tomeu: Is there a reason we're using hippo for the lists? |
10:12 |
|
GTK has a "sort-bar" control for lists, right? |
10:12 |
cms |
walterbender: i agree that alphabetical seems more intuitiv |
10:12 |
walterbender |
the reason I like it is that it is repeatable... |
10:13 |
eben |
walterbender: Yeah, that might be, at the very least, the correct default until we have a control which indicates the columns clearly. It might even always be the right choice. |
10:13 |
|
Yeah, I think you're right. Duplicating the time-ordered approach actually confuses it with the Journal... |
10:13 |
walterbender |
there are plenty of equivalents that are equally stable, but mod-time is not one of them |
10:13 |
eben |
Maybe we don't even need the date at all? |
10:14 |
cms |
eben: i agree--date doesn't seem necessary |
10:14 |
walterbender |
in the list view, probably not |
10:14 |
eben |
This is a list of activities for launching....alpha is a logical way to browse them. |
10:14 |
|
And we don't have dates for items in the other view....groups and neighborhood (once we add the lists there, which I want to put on the table for the next release!) |
10:15 |
cms |
eben: absolutely--that is the purpose of list view. i think the separation of list and ring/freeform is very effective |
10:15 |
eben |
So alpha makes sense in those as well, for sure. |
10:15 |
|
Great. Sounds like that's conclusive, then. Remove the date column entirely, sort by alpha. |
10:15 |
|
Maybe, for now, we should also label each "version 24" instead of just "24".... |
10:16 |
|
I know that will be redundant, but at least it would be clear. |
10:16 |
tomeu |
eben: was easier to get the desired look |
10:16 |
eben |
Right now those single integer numbers mean nothing. |
10:16 |
cms |
eben, tomeu: should i add a task? |
10:16 |
tomeu |
gtk has tree views, which are a bit of a pain to code, and can have sorting headers, yeah |
10:17 |
eben |
tomeu: gotcha, OK. Because we still have accessibility problems, and other details (sorting on cols) that we'll have to build ourselves... |
10:17 |
tomeu |
yeah, moving to a treeview would solve those |
10:17 |
eben |
tomeu: can we embed small canvases into each row, to get the same look, but wrap it in the GTK treeview? |
10:17 |
tomeu |
I think we could, but then you wouldn't have accessibility inside each row |
10:18 |
eben |
cms: Discussing the implementation of the list views....good time to consider it, since we plan on adding a number of other lists in the near term now. |
10:18 |
|
tomeu: That's still a big step in the right direction... |
10:18 |
|
But point taken... |
10:19 |
|
Let's not take the technical discussion too far at this point, then. |
10:19 |
|
Do folks agree with labeling versions "version x"? |
10:19 |
cms |
sure |
10:19 |
walterbender |
capital V, please |
10:20 |
eben |
And would exposing the tagging in the secondary palette be a good thing (more discoverable, easy to access) or a bad thing (since we'd rather force people to use the Journal to do this)? |
10:20 |
|
walterbender: heh, OK. |
10:20 |
cms |
eben: tagging seems fine in list view |
10:20 |
eben |
cms: You mean in the Journal? |
10:20 |
cms |
eben: in list view |
10:21 |
eben |
(palettes appear in both views) |
10:21 |
|
cms: Oh, you mean that each row should have the tags always shown in the list? |
10:21 |
cms |
eben: let me clarify something: are you imagining that you would have activity references in both list view and the journal? |
10:21 |
eben |
cms: Yes, naturally. Everything (I think) should live in the Journal. |
10:21 |
cms |
eben: so the list view in home is a filter of the journal |
10:22 |
eben |
The list view is an optimization which puts all the activities in one easy to access place. |
10:22 |
cms |
eben: i think that may potentially be confusing--why can't we separate journal from list view? |
10:22 |
eben |
That was our thought in designing it, wasn't it? |
10:22 |
|
cms: Because, activities have to be in the Journal. |
10:22 |
cms |
eben: i think we were thinking of the two being separate |
10:23 |
eben |
Otherwise you can't do things with them...like modify them. |
10:23 |
cms |
eben: the activity instances are, but the "raw" activities are in the Home list view |
10:23 |
eben |
No no. |
10:23 |
|
The activity itself...it appears in the Journal when you download it. |
10:23 |
|
It can be modified with develop; in the future, you could open it with a bundle activity, etc. |
10:23 |
cms |
eben: why doesn't it appear only in Home list view..? |
10:23 |
eben |
The activity is a "raw" activity, but it's still just an object. |
10:23 |
cms |
eben: i see |
10:24 |
|
eben: i'm recalling our earlier conversations |
10:25 |
eben |
So I'd actually like to emphasize that...make sure *every* activity (not just those downloaded by the kid) live in the Journal....make them managed (esp. deletion) only in the Journal....the list view is a launcher, but it's not the data store of activities. |
10:25 |
cms |
eben: that argument is making more sense to me now |
10:25 |
garycmartin |
eben: +1 |
10:25 |
walterbender |
eben: +1 |
10:25 |
cms |
eben: +1 |
10:25 |
eben |
hooray! :) |
10:26 |
|
he heh. |
10:26 |
cms |
#3: Home list view: remove the date column and enable alphabetical sort. Label versions "Version x" |
10:26 |
tomeu |
heh |
10:26 |
eben |
So, that brings me back around to the tagging question...and it seems that the answer might be: tagging is done in the Journal. |
10:26 |
cms |
eben: Well, there i disagree--since categories appear in the Home view, you'd want to manage them there as well |
10:27 |
eben |
Maybe the solution is to add a "Show in Journal" action to the secondary palette, so it's easy to jump to them to edit details... |
10:27 |
|
cms: They don't "appear" there, though....they are searchable. |
10:27 |
cms |
eben: "show in journal" makes sense, but i still think you'd want to tag activities from within the same context of your home view |
10:27 |
eben |
Home is an interface onto the activities, whereas the data store and management is in the Journal. |
10:28 |
cms |
it's more intuitive to keep that functionality in one place (though i suppose it could co-exist in the journal) |
10:28 |
eben |
I'm just playing devils advocate here, though. I was the one offering exposing the tag list in the secondary palette; but I wonder if that dilutes things, the same way that offering management via deletion dilutes things. |
10:28 |
cms |
i'm thinking more from the standpoint of the user |
10:28 |
eben |
cms: That's my point! |
10:29 |
|
tagging already lives in the Journal. |
10:29 |
|
So we get this "for free" if we use Journal tagging. |
10:29 |
cms |
eben: right, but again i'm thinking more experientially. as the user, you'd want categorization and filtering to be within the same space |
10:29 |
eben |
The question is whether or not we pull that feature into the Home view (or the activity palettes) also, I think. |
10:29 |
garycmartin |
eben: could it be a 'View details' like setup in the home view, 'sliding' off to the right to see the same things as view details from Journal, but with 'back' returning to the home view this time? |
10:30 |
eben |
garycmartin: That's what I was suggesting with "Show in Journal", yeah. |
10:30 |
cms |
garycmartin: that's a great idea |
10:30 |
eben |
cms: I think we might get away with exposing tags in the secondary palette, though.... |
10:30 |
|
the reason is: the palette exists both in Journal, AND in home... |
10:30 |
|
As long as the palette is consistent, it's not a problem for me. |
10:31 |
|
It becomes a natural extension. |
10:31 |
cms |
eben: my only point is that if we are enabling tagging/categorization as a key feature of Home, you should be able to assign categories there as well, not only filter |
10:31 |
|
i think we should create mockups of this |
10:32 |
eben |
cms: Is the palette is the place to do it? I think it might work... |
10:32 |
cms |
eben, can you formalize as a design task? |
10:32 |
|
eben: yes, i think the palette makes sense |
10:32 |
eben |
Sure. |
10:32 |
cms |
eben: though i also liked gary's idea |
10:32 |
eben |
cms: I think that's a valid addition either way, yeah. |
10:32 |
|
Oh, oh... |
10:32 |
|
I see...I misread that before. |
10:33 |
|
That's an interesting idea. |
10:33 |
|
But I again wonder if it confuses the list with the Journal again... |
10:33 |
|
Worth experimenting with. |
10:34 |
cms |
#4: Design mockups for tagging/filtering/search within Home view |
10:34 |
|
tomeu, when is the next release scheduled for? |
10:34 |
tomeu |
cms: in about 6 months from now |
10:34 |
eben |
#5: Draft changes to activity.info file to support tagging |
10:34 |
tomeu |
not really scheduled, but is when would be expected |
10:35 |
cms |
tomeu: how realistic is it to think about a revised groups view (incl. bulletin boards) within that timeframe? |
10:35 |
eben |
Quick technical question: Is the activity.info file translatable, at present? |
10:35 |
walterbender |
hopefully we will define a schedule in Paris |
10:35 |
eben |
We kind of need it to be, for tagging to work. |
10:35 |
tomeu |
cms: well, depends on the amount of work ;) |
10:35 |
eben |
cms: I thought Bulletin Boards were an activity, last we talked about them! |
10:35 |
walterbender |
eben: some fields, such as Activity name get translated |
10:35 |
tomeu |
eben: only the activity title |
10:36 |
eben |
OK, but support is there...so we could add more. |
10:36 |
|
cms: I think we should focus on the chat, actually... |
10:36 |
cms |
eben: that's right! so we should separate them from groups |
10:36 |
tomeu |
cms, eben: my opinion right now is that we won't be able to make big changes to the sugar code for 0.86 |
10:36 |
cms |
eben: mesh chat? |
10:36 |
eben |
Yes....I'm interested in getting activity (and then, once that's perfect, mesh/groups) chat built. |
10:37 |
tomeu |
because maintaining the current code base is already a substantial amount of work, including a shipped product like soas is |
10:37 |
cms |
eben: i agree, that's top priority |
10:37 |
tomeu |
but there are very interesting already underway in the activities space, which is less risky |
10:37 |
walterbender |
tomeu: let's get the ideas on the table and use Paris to decide what we can actually do |
10:37 |
tomeu |
yup |
10:37 |
eben |
And I'm also more interested in making groups "real" (like neighborhood...), and adding list views to groups and neighborhood. |
10:38 |
cms |
eben: can we list all these items and then discuss their feasibility? i think we've discussed them all before, it would make sense to quickly recap |
10:38 |
eben |
I think some of these details will solidify the idea of the zoom levels...add consistency and ease of use. |
10:39 |
|
" polish activity list in Home |
10:39 |
|
" support filtering/searching via tags in Home |
10:40 |
|
" add list views to groups/neighorhood |
10:40 |
|
" make groups dynamic (like neighborhood) |
10:40 |
|
" extend activity chat |
10:40 |
|
" add overlay chat to groups/neighborhood |
10:41 |
|
" design a bulletin-board _activity_ |
10:41 |
cms |
thanks eben! |
10:41 |
|
which of these points need more design work? |
10:41 |
eben |
" remove management from activity list, ensure _all_ installed activities are in Joural |
10:41 |
cms |
off-hand, i would say overlay chat, and the bulletin-board activity |
10:42 |
eben |
" new toolbar design |
10:42 |
|
cms: Yup. I agree. Those need the most. |
10:42 |
cms |
#6: Design mockups for overlay chat in groups/neighborhood |
10:43 |
|
#7: Design mockups of bulletin board activitiy |
10:43 |
eben |
(#6 should also include revising the activity chat..which exists but not as earlier designs proposed) |
10:44 |
cms |
eben: do we have earlier designs that we could fall back on? |
10:44 |
eben |
list views of groups/neighborhood might need a little design work, for instance to decide how grouping looks (wireless nodes, activities, people, etc.) |
10:45 |
|
Since there are multiple "types" of objects in those views, we need to do something smarter than just alphabetize them in aggregate, I think. |
10:45 |
cms |
#8: Design mockups for list views in groups and neighborhood |
10:45 |
eben |
cms: We do...they involved the "pop-out" messages which related to the right edge of the Frame... |
10:46 |
|
The current windowed version was meant to be the full-screen manifestation of that transient approach. |
10:46 |
cms |
let me just quickly confirm: does everyone else know what the list items refer to that eben just posted? |
10:46 |
|
or should we explain? |
10:47 |
garycmartin |
overlay chat is new to me, I have seen the bubble chat from right frame, but not overlay. |
10:47 |
tomeu |
I know what they refer to, but we need mockups to know what are you heading to |
10:47 |
eben |
Basic summary: we have a list view in Home now. We want to have list views in groups and neighborhood as well. This will make things consistent, and offer both scalability and accessibility (eventually) to all the zoom levels. |
10:48 |
|
garycmartin: We haven't produced any overlay chat proposals, recently. We had some rough mockups very early on (3? years ago)... |
10:49 |
cms |
gary: overlay chat needs to be detailed, but basically the idea was for a contextual chat in neighborhood/groups |
10:49 |
|
eben: has it been that long?! |
10:49 |
garycmartin |
OK, yea that's what I though. |
10:50 |
|
Reminds me of the concept of Chat Circles (MIT?) |
10:50 |
cms |
gary: yes, very similar. we referenced that work when we were thinking about the design |
10:50 |
garycmartin |
cms: cool |
10:51 |
cms |
great--well i think this was a good meeting to recap all of the pending design issues |
10:51 |
|
i'm going to have to jump off pretty soon, but before i do, wondering if we could recap all of the points and figure out who can work on what |
10:52 |
eben |
I think it's going to take at least a couple of weeks to pull together designs for the discussed areas... |
10:52 |
cms |
yes. |
10:52 |
eben |
So we should try to loosely address a schedule as we recap. |
10:52 |
cms |
maybe we should focus on several at a time |
10:52 |
|
ok |
10:52 |
walterbender |
can I raise one last topic? keyboard shortcuts? |
10:53 |
tomeu |
oh, that's a good one |
10:53 |
walterbender |
can we add shortcut hints to the view buttons? |
10:53 |
|
F1 F2 F3 F4? |
10:53 |
cms |
walterbender: good idea, that would help |
10:53 |
walterbender |
it may help with discovery on non-XO machines |
10:53 |
eben |
makes sense, yeah. |
10:53 |
|
How ubiquitous are shortcuts, these days? |
10:54 |
|
Nearly every button should have one, really. Both in the OS, and in activities. |
10:54 |
walterbender |
eben: It is easy to add them to toolbar buttons... |
10:54 |
tomeu |
it's also easy to add them to menuitems and tooltips |
10:54 |
eben |
walterbender: Right. I just wonder how many activity devs have added support for it....since it was broken for so long. |
10:55 |
|
Right...menu items also. Absolutely. |
10:55 |
garycmartin |
eben: labyrinth has them :-) |
10:55 |
eben |
In any case, we should make a push for all activities to support them, if they don't already. :) |
10:55 |
tomeu |
eben: we cannot wait for activity authors to implement it by themselves, we'll need to make a concerted effort and push for it |
10:55 |
|
including guidelines |
10:55 |
eben |
tomeu: right |
10:55 |
tomeu |
right ;) |
10:56 |
garycmartin |
tomeu: BTW any hint on using + and - as accelerators, the api didn't let me use then for zoom in and zoom out :-( |
10:57 |
tomeu |
garycmartin: dunno, but should be possible |
10:57 |
|
let's see what evince has |
10:57 |
|
evince uses ctrl++ and ctrl+- |
10:57 |
garycmartin |
tomeu: no rush just thought I'd mention it, the activity toolbar was only working with letters on numbers for me. |
10:58 |
walterbender |
garycmartin: maybe the activity team could organize weekly tutorials on some development tidbit each week on IRC |
10:58 |
|
garycmartin: the first one could be on adding keyboard shortcuts |
10:58 |
|
sort of a realtime almanac |
10:58 |
garycmartin |
walterbender: Nice idea, someone would have to teach me first, perhaps make it a peer shaing type thing :-) |
10:58 |
eben |
walterbender: that's a pretty excellent idea |
10:59 |
walterbender |
garycmartin: little, bites-ized topics... |
10:59 |
|
garycmartin: since I figured it out for TurtleArt, happy to lead that discussion... |
11:00 |
|
garycmartin: and someone else can help me with how to close a gplay window :) |
11:00 |
tomeu |
nice |
11:00 |
garycmartin |
walterbender: I'm too slow for realtime, my time is with my head stuck in the api docs and breaking stuff till it works (or not) |
11:01 |
|
walterbender: (but a great idea worth a try). |
11:02 |
walterbender |
garycmartin: I'll try it this week some time... |
11:03 |
cms |
tomeu: with the list of high-level features that eben posted, do you have enough info to be able to prioritize in terms of a development schedule? or do you need design mockups first in order to do that? |
11:04 |
tomeu |
cms: not really mockups, but we need to have an idea of what amount of work will tkae |
11:04 |
cms |
when is paris happening? |
11:04 |
tomeu |
but mockups help visualize the goals |
11:04 |
walterbender |
is going to have to take off in a minute... back in a couple of hours |
11:04 |
tomeu |
cms: http://wiki.sugarlabs.org/go/M[…]niCamp_Paris_2009 |
11:05 |
cms |
thanks for joining walter! |
11:05 |
walterbender |
cms: off topic: did you get the USB key I sent? |
11:05 |
cms |
walterbender: not yet, but i did get three sticks from caroline |
11:05 |
walterbender |
cms: I sent them to Pentagram |
11:05 |
|
^them^it |
11:05 |
cms |
walterbender: great, thanks so much. i'll check my mailbox on monday |
11:05 |
walterbender |
says thanks to all and bye for now |
11:06 |
tomeu |
cheers! |
11:06 |
cms |
walterbender: talk to you later! |
11:06 |
|
thanks for the link tomeu |
11:06 |
tomeu |
cms: planning to attend? ;) |
11:07 |
cms |
tomeu: i'd love to, but no funds... |
11:07 |
tomeu |
btw, marco may join us in paris: http://www.marcopg.org/2009/04/18/heartbeat/ |
11:07 |
|
cms: yeah, we need to get a sponsor quickly |
11:07 |
cms |
tomeu: let me know if you do find someone willing to pay travel expenses etc. |
11:08 |
|
so marco is still with us? haven't heard from him in a while |
11:08 |
tomeu |
cms: people are working on it, I tihnk walterbender and dfarning |
11:08 |
|
cms: he changed jobs (and countries) and had 2 crazy months |
11:09 |
cms |
tomeu: i heard... eben and marco are now working together... again! ;) |
11:09 |
tomeu |
cms: btw, I think pentagram works with litl? |
11:09 |
cms |
tomeu: yes! it's a small world |
11:09 |
tomeu |
eben: you are working for litl? |
11:09 |
|
heh |
11:09 |
garycmartin |
is it endmeeting time? |
11:09 |
tomeu |
yeah, you all are in a small world indeed :p |
11:09 |
eben |
tomeu: yup |
11:09 |
cms |
before we end: |
11:09 |
tomeu |
eben: congrats, looks like fun |
11:10 |
cms |
i was going to suggest that we work on the design mockups in time for the paris meeting |
11:10 |
|
that gives us about four weeks |
11:10 |
tomeu |
in a not so far future, the sugar shell may be rewritten in js, to reuse all the work going into gnome 3.0 and litl's stuff |
11:10 |
cms |
and it would help us create a development schedule during sugarcamp |
11:10 |
tomeu |
cms: that would be awesome |
11:11 |
cms |
my only issue is that i'm finishing teaching in two weeks |
11:11 |
|
after that, i'll be free to work on these mockups |
11:11 |
|
eben, how is your schedule looking? |
11:11 |
eben |
cms: decent |
11:11 |
|
I have some spare time. |
11:12 |
cms |
great--maybe you could get a headstart with some of these comps, and i'll pitch in one my course ends? |
11:13 |
|
maybe we can present them in advance of sugarcamp, or even during, remotely |
11:14 |
eben |
Yeah, that sounds good |
11:15 |
cms |
excellent |
11:15 |
|
thanks everyone for a productive meeting today! |
11:15 |
|
any last thoughts, or should we break? |
11:16 |
|
i'll post a recap to the wiki |
11:17 |
garycmartin |
cms: thanks for the meeting, covered good ground! |
11:17 |
eben |
bye all! |
11:17 |
cms |
talk to you soon! |
11:17 |
|
#endmeeting |