| Time | Nick | Message |
|---|---|---|
| 09:41 | erikos | cms: thanks |
| 09:42 | cms | so, about the simple toolbar |
| 09:42 | erikos | #TOPIC Design meeting - 0.86 |
| 09:42 | cms | our feeling is that we should have a default single toolbar for activities that don't require multiple levels |
| 09:43 | tomeu | +1 |
| 09:43 | cms | in the case of the simple activity, the functions within the activity tab should move up into the main toolbar |
| 09:43 | alsroot | should we leave simple toolbars(e.g. in Chat) as is or use something like this http://people.sugarlabs.org/~a[…]/Chat-toolbar.png (to have activity icon)? |
| 09:43 | cms | alsroot--looks good, can you explain? |
| 09:44 | garycmartin | alsroot: I think the activity icon is now an important element all primary toolbars should have. |
| 09:44 | alsroot | garycmartin emaild about having activity icon in simple toolbars(like in toolbars with subwidgets) |
| 09:45 | cms | it probably makes sense, although it doesn't look like we have any functionality in it |
| 09:45 | alsroot | and the Q is what should it provide, only title name? |
| 09:45 | eben | Yes, I definitely see the desire to have the icon there; I'm torn about what to do with it. |
| 09:45 | cms | don't forget that we also use it in the frame |
| 09:45 | alsroot | s/it/activity icon/ |
| 09:45 | garycmartin | cms: I think the main question seems to be, what, if any, function should the icon have in the simple toolbar case. |
| 09:46 | cms | garycmartin: right, that's the question. we could put some of the functionality on the right of the toolbar inside the menu, potentially |
| 09:46 | eben: i'm a bit torn, also, since it already exists in the frame | |
| 09:46 | erikos | I think it is just visual consistency, but we could put the 'tag option', 'add description option' there for example |
| 09:47 | eben | right, but here it's the identifier... |
| 09:47 | cms | good point |
| 09:47 | but--i think it needs to be consistent with the icon in the frame | |
| 09:47 | at least | |
| 09:47 | otherwise it could easily be confusing | |
| 09:47 | eben | Well, then we'd duplicate all the functions. |
| 09:47 | garycmartin | cms: the new toolbar design means we have to have an activity icon (unless you like my previous toolbar mockups) so adding the icon to the minimal toolbar case is just for visual consistancy. |
| 09:48 | eben | And it would still behave differently in "non-simple" activities |
| 09:48 | garycmartin: right | |
| 09:48 | cms: For other activities, the activity icon is the toolbar button that reveals the secondary activity toolbar | |
| 09:48 | cms | it would be better if we had a more consistent solution, but i see why/how this came about |
| 09:49 | eben: right, but i think there is some confusion in having it behave differently, depending on the activitiy | |
| 09:49 | we are building up expectations by having it, that if they aren't met could lead to frustration | |
| 09:50 | i'm wondering if visual consistency is really the most important thing here | |
| 09:50 | eben | right, but at the same time we're talking about tossing out the iconic identifier of the activity, which is shown everywhere else in the UI. |
| 09:50 | cms | well, we didn't have it prior to this new design |
| 09:50 | garycmartin | cms: as an example, Write has had a number of icon with no function as part of its toolbar design. Where the icon indicates what a neighbouring control is for. |
| 09:51 | erikos | eben: maybe using the activity icon is not the best, and another icon would be better |
| 09:51 | cms | garycmartin: i'd have to see it, but that doesn't seem ideal |
| 09:51 | eben | cms: true, but I think it's a rather useful addition, especially in the non-simple case when the title isn't shown either. |
| 09:52 | erikos | eben: for title, keep, tags, description - the journal icon would be appropriate as well |
| 09:52 | cms | well, thinking about it, maybe what we need is a "label" icon, to satisfy this issue and also what garycmartin was just mentioning |
| 09:52 | eben | erikos: I think that would be confused with "keep" then; in the Frame, we use the activity icon to hold this same set of functionality, so I think it's the logical choice. |
| 09:52 | cms | it could be an inactive activity icon, as a label for the toolbar |
| 09:53 | eben | cms: That seems to send the wrong message, though. |
| 09:53 | cms | eben: what we want to avoid is two types of activity icons that look the same but do different things |
| 09:53 | eben | well, we already have that. :-P sometimes it reveals a palette, and other times a toolbar. |
| 09:54 | But in both cases, it reveals the same set of functionality. | |
| 09:54 | cms | well, no, i mean icons that literally look the same |
| 09:54 | erikos | eben: yeah, the journal icon is not the right one, neither |
| 09:55 | eben | cms: I'm actually leaning toward making it a "label": no highlight on hover, no palette. |
| 09:55 | cms | i'd argue for consistency, since i can predict it will cause confusion otherwise |
| 09:55 | eben: right, i think that may be a good solution | |
| 09:55 | eben: either that, or dropping it entirely (which may also work i'm thinking) | |
| 09:56 | what does everyone think about making the activity icon a label? (= inactive) | |
| 09:57 | garycmartin | cms: activity icon as inactive label (no highlight, no palette) for the minimal toolbar use case +1 |
| 09:57 | alsroot | cms: and how it will look for complicated toolbars(w/ subbars)? there will be another button in main bar to open activity related widgets? |
| 09:58 | cms | alsroot: right--in that case the activity icon would be highlighted, in color, and open the secondary toolbar |
| 09:59 | this seems like a good solution, and give us the visual consistency that people feel is important to have | |
| 09:59 | garycmartin | cms: (activity icon should always be in colour, sub toolbar or no sub toolbar, just to confirm) |
| 09:59 | alsroot | cms: so, active "activity icon" in complicated case and inactive in simple one? |
| 10:00 | cms | garycmartin: actually, was thinking it would be b/w, or grayed out |
| 10:00 | garycmartin: otherwise i might think it is active as a ui element | |
| 10:00 | eben | cms: oh...I think the colors need to stay actually |
| 10:00 | It just wouldn't have any hover indication | |
| 10:00 | cms | eben: but then the expectation is that i can interact with it |
| 10:01 | eben | cms: I don't think that's going to be a common problem, because all the control you'd be looking for is already right in front of you. |
| 10:01 | garycmartin | cms: The colour is all part of the identity. Making it B/w or monochrome in some way might make it like a bundle or a new activity. |
| 10:01 | eben | It doesn't do it's job as a label if it doesn't retain the colors. |
| 10:01 | cms | what i was thinking is that we could design a new class of toolbar icon, which acts as a label for a grouping of elements |
| 10:02 | the activity icon could be part of this system | |
| 10:02 | eben | cms: that's already being done. |
| 10:02 | cms | i agree with the points about color, but worry that the icon would still feel active to the user |
| 10:03 | quick poll: dropping the icon altogether in simple activity toolbars? | |
| 10:03 | eben | I think making it uncolored would be more confusing, since it would imply "this activity isn't running" |
| 10:04 | garycmartin | cms: I have a similar concern. But it's best of a bad bunch of choices (and the simplest to implement re erikos previous comments on making it disclose the title/share/keep to the right) |
| 10:04 | cms | actually, there may be another solution here |
| 10:05 | why not keep all the activity options inside a palette, like we currently have in the frame? except the icon would also be inside every toolbar | |
| 10:05 | the difference is we wouldn't need a secondary toolbar, but instead it would always just be a palette | |
| 10:05 | eben | Then you lose the ability to have the toolbar in non-simple activities. |
| 10:05 | cms | eben: why? |
| 10:06 | eben: you mean the activity toolbar? | |
| 10:06 | eben | Because the palette would be the same button as the toolbar, no? |
| 10:06 | cms | that's my point |
| 10:06 | eben | yeah |
| 10:06 | cms | let's make the activity toolbar a palette, thoughout |
| 10:06 | that would also make it more consistent with the frame | |
| 10:07 | alsroot | cms: in that case for non-simple activities we need place large title entry somewhere |
| 10:07 | cms | we could still (optionally) call-out special functions, like stop or keep in the main toolbar, if necessary |
| 10:07 | eben | Well, there's lots more functionality in the activity toolbar: entering a title, a palette with UI for sharing (eventually), submenus for Keep with other controls like "keep a copy" or "keep as PDF", etc. |
| 10:07 | cms | eben: but couldn't that go inside a palette? |
| 10:08 | eben | cms: Well, there might be a way. But it's not going to happen by Thurs, I bet. |
| 10:08 | cms | well, i'm generally on-board with the previous approach, and color may be fine |
| 10:08 | garycmartin | cms: OK, so no 'lock open' of the palette, and the title input area might feel a little tricky to use (have to leave the cursor in the palette while typing). |
| 10:08 | eben | We'd have to go through some design cycles to figure out if we can pack title, sharing, extended keep, etc. in one palette. |
| 10:09 | cms | as long as we have the toolbar arrow-indicator for non-simple activities |
| 10:09 | garycmartin: agreed | |
| 10:09 | maybe i'm coming around to this: http://people.sugarlabs.org/~a[…]/Chat-toolbar.png | |
| 10:09 | it seems that if the icon is colored, having at least a label is necessary | |
| 10:10 | erikos | cms: yup, that sounds right as well |
| 10:10 | cms: the user needs feedback - and it it is just the title | |
| 10:10 | s/it/if | |
| 10:10 | cms | erikos: right |
| 10:11 | ok--that seems like a good solution... | |
| 10:11 | erikos | everyone d'accord? |
| 10:11 | eben | sounds good |
| 10:12 | erikos | likes it too |
| 10:12 | cms | +1 |
| 10:12 | eben | I've got to leave in about 15 minutes, just for the record. What other topics are least decided? |
| 10:12 | cms | we can move on to labels |
| 10:12 | eben and i had a simple solution | |
| 10:12 | erikos | yup - gary fine to you as well? |
| 10:13 | garycmartin: ^^ | |
| 10:13 | cms: you might want to explain the labels already | |
| 10:13 | cms | well, after having debated it extensively, we think the best solution is to use tooltips |
| 10:14 | they are already in the system, and were the only method we could think of that doesn't undermine toolbar functionality as it currently stands | |
| 10:15 | what do you think? | |
| 10:15 | erikos | cms: http://wiki.sugarlabs.org/go/F[…]rowse-toolbar.png |
| 10:15 | cms: can you describe how that would look like here | |
| 10:15 | cms | sure |
| 10:15 | erikos | cms: let's say for edit |
| 10:16 | cms | so, if you hover over the edit toolbar icon, you would simply get a tooltip saying "edit" over the icon |
| 10:16 | the toolbar would still appear on hover | |
| 10:16 | clicking would lock in the toolbar, and cause the tooltip to disappear | |
| 10:16 | garycmartin | erikos: +.7 (as long as activity icon label always matches the title input)... |
| 10:17 | alsroot | cms: didn't get it, "a tooltip saying "edit" over the icon" and later "toolbar would still appear on hover" ? |
| 10:17 | cms | garycmartin: i agree with the title input... |
| 10:17 | alsroot: sorry, let me explain | |
| 10:17 | so, rolling over a toolbar icon would cause the sub-toolbar to appear (on hover) | |
| 10:17 | erikos | garycmartin: yeah, so they both match - sounds good |
| 10:18 | eben | what matches? |
| 10:18 | cms | in addition, we would have a tooltip appear (on slight delay as well) describing the icon/toolbar (in this case "edit") |
| 10:18 | erikos | eben: the title in the palette and in the text entry field |
| 10:19 | alsroot | cms: tooltip will overlap "sub-toolbar to appear (on hover)" ? |
| 10:19 | eben | There is no title on the toolbar, just in the tooltip. |
| 10:19 | erikos | eben: http://people.sugarlabs.org/~a[…]/Chat-toolbar.png |
| 10:19 | eben | oh, old topic. |
| 10:19 | sorry. | |
| 10:19 | garycmartin | cms: when you hover over a icon for a sub palette, the palette does reveal so you can quickly get something without locking it. |
| 10:19 | cms | alsroot: right. it could overlap the icon/toolbar below. but tooltips are small, so shouldn't obstruct |
| 10:20 | garycmartin: right, and so we are suggesting in addition a tooltip describing the icon/toolbar | |
| 10:20 | that's all, just an additional tooltip | |
| 10:20 | eben | cms: and, more importantly, they don't obstruct clicks, and fade out when moving off the control. |
| 10:20 | cms | eben: exactly |
| 10:21 | alsroot | cms: well, I'm not a designer :) but it looks a bit ugly for me(I tried that) |
| 10:21 | cms | alsroot: i think it would be fine. but if you tried it, might be good to see... |
| 10:21 | alsroot | I mean overlapping |
| 10:21 | garycmartin | alsroot: 'bit (butt) ugly' +1 :-) |
| 10:21 | eben | alsroot: agreed. It's not visually pleasing, but it's serving a utilitarian purpose, and most of the time will never appear (once you know what the toolbar is). |
| 10:21 | (The delay on the tooltip needs to be longer than the delay on showing the palette!) | |
| 10:21 | cms | alsroot: we could maybe always position it above the sub-toolbar so they don't overlay |
| 10:21 | erikos | eben: or we add a preference for it |
| 10:22 | eben | er, toolbar....not palette. |
| 10:22 | cms | there is another possibility: |
| 10:22 | eben | erikos: I don't think we need a preference, as long as it is on a delay. |
| 10:23 | cms | we could (a) use a palette that turns into a sub-toolbar on delay, or (b) add a label below the sub-toolbar (less aesthetically pleasing than tooltips i fear) |
| 10:23 | erikos | eben: ok, would be good to try it, worth it |
| 10:23 | alsroot | btw maybe having label at left corner of appeared palette/subbar |
| 10:23 | cms | alsroot: thought of that but it takes up too much space |
| 10:23 | alsroot | yeah |
| 10:23 | eben | alsroot: the problem is, anything in the toolbar will obstruct the controls, which are meant to be actionable even on over, without locking it in. |
| 10:24 | cms | eben: what do you think about a palette turning into a toolbar? |
| 10:24 | eben | The other option is to put a label down beneath the toolbar, but then the "locking in" step isn't as clear, since the label just disappears (or if it doesn't, it wastes lots of space). |
| 10:24 | cms | so we could have the description appear for a few secs, then transition to the full toolbar |
| 10:25 | eben | Hmm. That kind of defeats the purpose of making it actionable on hover. |
| 10:25 | cms | eben: true |
| 10:25 | eben | Since you'd have to wait for it every time. |
| 10:25 | erikos | cms: our arrow is a bit big, so the tooltip is not really visible (just tried quickly) |
| 10:25 | cms | erikos: do you have a screenshot? |
| 10:26 | alsroot | btw in case of "palette turning into a toolbar" we follow common palette behaviour - first title/second palette |
| 10:26 | erikos | cms: one sec |
| 10:26 | eben | isn't the tooltip on top of everything? |
| 10:26 | alsroot: what do you mean by that? What's the "title" phase of the toolbar? | |
| 10:26 | garycmartin | eben... ooooh, can we use custom cursors with the string in? Sounds like big engineering though... |
| 10:27 | eben | Ideally, on delayed hover the entire toolbar should appear. |
| 10:27 | garycmartin | (so your pointer gives you the hover hint feedback text) |
| 10:27 | alsroot | eben: I man tooltip appears firstly then after right click palette will appear - that in common case -- in case of "palette turning into a toolbar" we have the same ehaviour |
| 10:28 | erikos | cms: http://people.sugarlabs.org/~erikos/tooltip.png |
| 10:28 | eben | garycmartin: basically the same as a tooltip, no? Except it moves with the mouse, making it harder to read, potentially. |
| 10:28 | erikos | cms: there might be options I can set, though |
| 10:28 | looks | |
| 10:28 | eben | alsroot: But there is no "primary palette" for toolbars. |
| 10:28 | cms | erikos: that looks ok, except that we need to move the tooltip out from under the mouse pointer! |
| 10:28 | eben | The toolbar should be the first order reveal. |
| 10:29 | garycmartin | eben: yes, but as part of the cursor you never cover it, and it always tells you what toolbar you are hovering in at all times. |
| 10:29 | cms | but otherwise i think this is the best approach given the parameters |
| 10:29 | eben | well, the (x,y) offset is just wrong, right? |
| 10:29 | cms | we could, of course, decide to not do toolbar-hovers and replace with a description/palette until clicked |
| 10:29 | eben | Usually tooltips overlap none of the cursor when they first appear. |
| 10:30 | If you move the cursor, the tooltip stays, and you can cover it with the cursor then. | |
| 10:31 | cms | eben: what about forfeiting toolbar-hovers? |
| 10:31 | eben | So if we can adjust the initial position, this would be an acceptable solution. |
| 10:31 | cms | eben: i agree |
| 10:31 | eben | We could...it seems like a big sacrifice for a once-needed label, though. |
| 10:32 | garycmartin | cms, toolbar-hovers help in cases when a canvas redraw is cpu expensive, locking open a sub-toolbar triggers a canvas redraw to make space... |
| 10:32 | eben | Maybe the hover reveal will confuse kids anyway....I'm not sure. |
| 10:32 | But it does seem annoying to make eg. selecting a color to paint with a 3 click operation. | |
| 10:33 | (and one that shifts the canvas around...that's the bigger issue, really) | |
| 10:33 | cms | eben: i personally don't know that the toolbar-hovers are necessary, but willing to accept either solution! |
| 10:33 | eben | garycmartin: yup, indeed. |
| 10:33 | cms | garycmartin: that's actually a good point |
| 10:33 | in that case, is everyone on-board with tooltips for now? | |
| 10:34 | (if we need them at all, that is) | |
| 10:34 | eben | My opinion is that it's a good (and easy to do) short term solution, that might stick. |
| 10:34 | garycmartin | cms: need to see it in action or a screen shot. If it's on a long delay I might not care (and most will never see it any way...) |
| 10:34 | eben | As long as we can offset them correctly, and as long as they appear after the toolbar, and not with or before. |
| 10:35 | erikos | eben: yeah, have not seen options for that yet :/ |
| 10:36 | eben | Alright, I've gotta run, everyone. I'm sorry to be missing out on the tabs and tags discussions. :-/ |
| 10:36 | erikos | eben: we keep you updated |
| 10:36 | eben | But good luck with the release everyone! |
| 10:36 | I'll be in touch. | |
| 10:36 | erikos | eben: thanks for joining in! |
| 10:36 | ok, so next point? | |
| 10:36 | garycmartin | Thanks eben! |
| 10:37 | erikos: Should the keep and shar icons be left or right aligned? | |
| 10:38 | cms | garycmartin: i'd be more in favor of left-alignment |
| 10:38 | alsroot | btw on large screen having share and keep buttons on the right could be useless |
| 10:38 | garycmartin | erikos: there was some discussion that putting them near the activity toolbar icon would reduce cursor pointer errors (i.e. make them left aligned). |
| 10:39 | erikos | garycmartin: right, I would prefer left |
| 10:39 | garycmartin | erikos: +1 |
| 10:39 | cms | excellent, +1 |
| 10:40 | erikos | next item |
| 10:40 | cms | should we move on to tags/tabs? |
| 10:40 | garycmartin | erikos: and how would the minimal toolbar place them, left aligned as well? |
| 10:40 | erikos | breaks |
| 10:40 | cms | i again opt for left-aligned |
| 10:40 | erikos | agrees |
| 10:40 | garycmartin | cms: +1 |
| 10:41 | erikos | puts gear one back in |
| 10:41 | * Tags in Journal | |
| 10:41 | http://wiki.sugarlabs.org/go/F[…]s/Tags_in_Journal | |
| 10:41 | garycmartin: you had some mockups here already, correct? | |
| 10:41 | garycmartin | erikos: yea |
| 10:41 | erikos | http://wiki.sugarlabs.org/go/D[…]Proposals/Journal , I guess |
| 10:42 | cms | ah |
| 10:42 | erikos | garycmartin: maybe you want to introduce us, then |
| 10:42 | garycmartin | erikos: that's it |
| 10:42 | cms | is this intended for the next relase? |
| 10:42 | alsroot | cms: I guess for 0.86 |
| 10:42 | erikos | cms: aleksey would like to code it, yes |
| 10:43 | alsroot | s/guess/hope/ |
| 10:43 | garycmartin | Well, lots of ideas on this page, some more likely than others... |
| 10:43 | cms | the tags seem too much, imo |
| 10:43 | erikos | cms: you mean, a too big task to get done in a few days? |
| 10:43 | cms | you should see them in the detail view, but i don't think it's necessary to show them here |
| 10:43 | no, speaking in design-termsn | |
| 10:43 | erikos | ok |
| 10:44 | cms | rather than showing them here, i think we need to get people to click through to the detailed view |
| 10:44 | garycmartin | cms: Just this type of treatment, or showing them at all? |
| 10:44 | cms | i guess showing them at all |
| 10:44 | alsroot | cms: maybe we can push the first roll for 0.86 and improve it in 0.88 |
| 10:44 | cms | though there may be a better treatment |
| 10:45 | garycmartin | cms: the issue is that tags are not exposed enough in the UI. The deatils view is too far away. |
| 10:45 | cms | well, when i look at this it makes the journal instantly more complex |
| 10:45 | erikos | I had the idea, of adding a widget for tags and the description to the activity toolbar, like we have for the title |
| 10:45 | cms | garycmartin: to your point, i think a better solution would be to make the detail view feel more connected |
| 10:46 | if we can get people comfortable with switching between the two states, then we wouldn't have a need for tags in this view | |
| 10:46 | i tend to agree that, currently, details feels too far | |
| 10:46 | and to offer another suggestion: tags could potentially be shown on rollover | |
| 10:46 | garycmartin | cms: it's the context switch I think is the current problem. Folks don't seem to use it much. |
| 10:47 | cms | it's just that seeing everything at once makes the information very difficult to parse |
| 10:48 | garycmartin: we could probably revisit that altogether. detail view was the place for this type of functionality. if the mode-switch isn't working, then that is the design problem we should aim to solve | |
| 10:48 | i.e., instead of switching screens, maybe the information appears over the current view, like a lightbox | |
| 10:48 | there are many possible solutions | |
| 10:48 | erikos | cms: good points you are bringing up |
| 10:48 | garycmartin | cms: the idea with the tags was also that clicking on would add it to the current search query. That way you could drill down into your entries via tags, no typing necessary. |
| 10:49 | erikos | garycmartin: ahh, that sounds interesting |
| 10:49 | cms | garycmartin: that's a good idea. i wonder then if we could show them elsewhere, as a full list of categories to choose from? i think google docs uses a similar mechanism |
| 10:49 | erikos | cms: or blogs does |
| 10:50 | cms | the problem with this approach (well intentioned, i know!), is that you see a lot of information repeated |
| 10:50 | erikos | cms: I think aleksey has done it like that in the library activity |
| 10:50 | cms: with a 'tag cloud' at the right side | |
| 10:50 | garycmartin | cms: How about an extra column that had a tag icon, clicking it would reval a palette with the tags in (and potentially clickable) |
| 10:50 | cms | if instead you grouped all tags in one menu (or in another way) you would eliminate redundancy |
| 10:50 | garycmartin: that could work, although a palette may be better | |
| 10:50 | to avoid confusion with the timeline | |
| 10:51 | but bother are options we should probably explore | |
| 10:51 | both, sorry ;) | |
| 10:51 | generally, i think this is going in the right direction--tags are currently underutilized | |
| 10:51 | we could try to put something together before feature freeze | |
| 10:52 | (how much time is left?) | |
| 10:52 | garycmartin | cms: if they all go in one master palette (see the Journal mockups further down the page) it does mean it can get very large. |
| 10:52 | cms | hmm, yes |
| 10:52 | that, too, could use some additional thought | |
| 10:52 | erikos | cms: we have to land it on thursday |
| 10:52 | cms: thursday night | |
| 10:52 | cms | ok |
| 10:52 | garycmartin | cms: you'd only need to show a tag icon next to a Journal entry if indeed it had any tags added. |
| 10:53 | cms | i actually think this may warrant more time |
| 10:53 | we need to get deeper into some of this functionality | |
| 10:53 | including the detail view, | |
| 10:53 | alsroot | garycmartin: btw how about having all "filter" buttons under one button and use some kind of tabs in palette to switch between them -- I mean in that case we can have huge search bar |
| 10:53 | cms | and palettes of the complexity they are being shown in the journal mockups |
| 10:53 | garycmartin | cms: A little like 'buddies' only show up next to an entry if it was shared, there is no 'grey buddy icon' always there. |
| 10:54 | cms | garycmartin: your idea of having a column appear on clicking a button in the toolbar actually sounds like a good one |
| 10:54 | garycmartin: but will need to try it to see | |
| 10:55 | when is feature freeze for the next release? | |
| 10:55 | i'd like to give more thought to these, and worried that thursday is not enough time | |
| 10:55 | erikos | cms: we have a 6 months cycle |
| 10:55 | cms: so roughly in 6 months | |
| 10:55 | cms | hmm ok |
| 10:56 | actually, the tags palette doesn't look bad.... | |
| 10:56 | garycmartin | cms: not so much a "column appearing" I was going closer to you "show tags on hover over entry" idea, I was just adding a little tag icon so users would know there was something on that entry to actually see. |
| 10:56 | cms | http://wiki.sugarlabs.org/go/F[…]_tags_palette.png |
| 10:56 | erikos | cms: but I agree, design decisions take time, if you want to do it right |
| 10:57 | cms | garycmartin: i think that could possibly work, though i wonder how useful it wouldbe |
| 10:57 | garycmartin | cms: sure :-) |
| 10:57 | cms | maybe the question is, of all of these idea, is there one that we should try to solve by thursday? |
| 10:57 | we could then work collaboratively to come up with the best solution | |
| 10:57 | but i don't think we can tackle all of them | |
| 10:58 | we could try to come up with a good solution for tags | |
| 10:58 | garycmartin | cms: a master tags palette could be something to shoot for, but the Journal toolbar is going to be a bit of a mess without a larger rework (perhaps like some of the mockups show) |
| 10:59 | cms | right-- |
| 10:59 | i'm concerned that we won't have enough time to properly address the journal toolbar | |
| 10:59 | erikos | garycmartin: yeah, I was just remembering the journal toolbar rework - we did not do yet |
| 10:59 | cms | what motivated those changes? |
| 10:59 | garycmartin | erikos: no grid view :-( |
| 11:00 | erikos | garycmartin: yeah :( |
| 11:00 | cms | if i understood the rational more, i could help advise for better treatments |
| 11:00 | for instance, i think the drop downs worked better than the icons | |
| 11:00 | erikos | cms: for the journal toolbar redesign? |
| 11:00 | cms | erikos: yeah |
| 11:00 | i'm seeing that the drop downs were replaced with icons | |
| 11:00 | erikos | cms: I think mostly space concerns |
| 11:01 | cms | the tags icon works, but the other three seem unclear |
| 11:01 | garycmartin | cms: It started with the issue for the "Anything" filter. It get's way too long and you have to scroll for 5-10 seconds to get through the list of activities. I started by trying to show this information on a palette in a grid layout. |
| 11:01 | cms | garycmartin: yeah, the grid has potential |
| 11:01 | that list would be very long | |
| 11:02 | i think i would save this for the next round, though | |
| 11:02 | there are so many design decisions to make here that i'm not sure we'll get around to all of them by thursday | |
| 11:02 | instead, we could focus on tags, and come up with a really good solution for integrating them better | |
| 11:03 | garycmartin | cms: then space needs seemed to be the issue, the long text dropdowns eat a lot of the toolbar, especialy if you want grid vs list view, or perhaps the object vs action toplevel switch. |
| 11:03 | cms | garycmartin: i can take a look at that. i think we can solve the space issues with some small adjustments (like making the search box shorter) |
| 11:04 | if you think we can do everything by thursday, we can certainly try, but i'm worried that we won't be able give enough thought to many of the issues | |
| 11:05 | i could mockup some treatments for the journal toolbar (solving the space issue) and the tag integration within the next day or two | |
| 11:05 | then we could all review again and see where we are | |
| 11:05 | garycmartin | cms: oh no way, I'd be suprised if any of this make it now, and they were just ideas from 2 or so months back to try and get things moving (not much did). |
| 11:06 | cms | ah, i see. whew ;) |
| 11:06 | but i agree these are all really valid concerns | |
| 11:06 | we should try to get at least tags in by thursday, no? | |
| 11:07 | who is working on journal? | |
| 11:07 | erikos | cms: what would tags cover? |
| 11:07 | cms | (on the implementation i mean) |
| 11:07 | garycmartin | What do others think regarding tags? I'm not sure we have developer bandwidth right now. |
| 11:07 | erikos | cms: aleksey wants to work on it |
| 11:08 | cms | i think finding a solution for integrating them as filters in journal |
| 11:08 | erikos | cms: so 'just' a filter |
| 11:08 | cms | erikos: i think so |
| 11:08 | and, we can think about a rollover on each entry | |
| 11:08 | erikos | cms: how about a widget to add them in the activity directly? |
| 11:08 | garycmartin | cms alsroot, so I'd say Grid view would be more useful that Tags, if we only get to do one... |
| 11:09 | cms | erikos: maybe paired with the title field, sure |
| 11:09 | garycmartin: we can try to solve for that. i think it's very close | |
| 11:10 | garycmartin: just to be clear, you mean the palette grid view...? | |
| 11:10 | garycmartin | cms: I think most kids will leave the Journal in grid view. It'll be much more friendly for them. |
| 11:10 | erikos | garycmartin: recent mockups? |
| 11:10 | cms | oh, so you mean the actual grid view |
| 11:10 | we had mockups of that a long time ago | |
| 11:11 | i can try to dig them up | |
| 11:11 | garycmartin | cms: No not palette grid view. Grid layout of Journal entries (thumb nail view) |
| 11:11 | cms | graycmartin: got it. i agree--grid view would be great to have |
| 11:11 | garycmartin | erikos: mockups, I think Ebens original designs, and alsroot Library grid view are both pretty close. |
| 11:11 | cms | the idea for grid view was that it would show the contents of an activity (the screenshot also stored in detail view) |
| 11:12 | garycmartin | cms yep +1 |
| 11:12 | cms | garycmartin: i still have the mockups from earlier on when we first proposed this, will look for them |
| 11:12 | erikos | I guess in general, we should focus on one of those items |
| 11:13 | cms | tough decision |
| 11:13 | alsroot | so, grid view is another feature to include to 0.86? if there is not design related issues and eben's mockup is good I guess it shoudl be a problem to have it in 0.86 |
| 11:13 | garycmartin | cms: alsroot and his Library Activity already do all this (and a bunch of other stuff we are talking about). |
| 11:13 | cms | maybe i agree with gary, that grid view would be a more essential problem to solve initially |
| 11:13 | erikos | alsroot: a / no ? |
| 11:13 | alsroot | s/it shoudl be/it shouldn't be/ |
| 11:13 | I meant :) | |
| 11:13 | erikos | ok ;p |
| 11:14 | cms | ok let's summarize |
| 11:14 | are we going to try to address (a) grid or (b) tags? | |
| 11:14 | or (c) neither | |
| 11:15 | what can we accomplish with this release? | |
| 11:15 | garycmartin | (d) go get a cold beer (or two) |
| 11:15 | erikos | garycmartin: that would be the tomeunesque solution |
| 11:16 | cms | i'm in for (d) ;) |
| 11:16 | alsroot | I really hope that we will have some kind of (b) in 0.86 |
| 11:16 | cms | ok, how about this |
| 11:16 | erikos | alsroot: you think b as more important then a ? |
| 11:16 | garycmartin | cms: if we go for Thumbnail view, we need 2 new icons (like the home view) [thumb view] [list view] so we will need to make some space in the Journal toolbar (maybe shrinking the search would be enough). |
| 11:16 | erikos | listens to cms |
| 11:17 | alsroot | a) is not a problem, I mean |
| 11:17 | :) | |
| 11:17 | cms | i can spend some time working on tags in the next day or two |
| 11:17 | and i'll also dig up the grid view mockups | |
| 11:17 | then we can collectively decide which of the two to do | |
| 11:17 | we can reconvene next week, say wed morning | |
| 11:18 | alsroot | I thought we already have ready to use eben's mockup for thumb view? |
| 11:18 | garycmartin | http://wiki.sugarlabs.org/go/D[…]m/Designs/Journal ...and it is about at image 10 |
| 11:18 | cms | great, there it is |
| 11:19 | erikos | http://wiki.sugarlabs.org/go/D[…]esigns/Journal#10 |
| 11:19 | cms | though as gary says, we'll need to reconfigure the journal toolbar if we want to do this |
| 11:20 | garycmartin | cms personally I'd put the details view icon up under the fav star icon, but that's a trivial call :-) |
| 11:20 | cms | well, i think detail view needs to be invoked for each entry |
| 11:20 | but maybe it would be better in a lightbox overlay | |
| 11:21 | (similar to preferences, perhaps) | |
| 11:21 | erikos | I think, the grid view has some details as well, that are not done quickly |
| 11:21 | audio preview, the toolbar... | |
| 11:22 | garycmartin | cms: sorry to be clear. Every entry has a detail view icon. Just rather than it floating below all on it's own, it should be with the other icons. |
| 11:22 | cms | hmm |
| 11:22 | what happened to checkboxes? | |
| 11:22 | that was a useful feature | |
| 11:22 | garycmartin | cms checkboxes, only usefull once we have multi select operations... |
| 11:23 | cms | so where do we leave this? |
| 11:23 | i have to run in a few mins | |
| 11:23 | erikos | from a general timeline: I think we would need on an item we want to tackle today, and a first mockup, implement it then in the next days - meet again to reiterate over it |
| 11:23 | cms | does grid view seem like something we can accomplish? |
| 11:23 | erikos | to have a chance for thursday |
| 11:23 | cms | erikos: sounds good |
| 11:23 | garycmartin | cms: My suggestion was to save the space all those boxes eat (and make things complicated) and use Shift and/or Ctrl to multi-select. The treeview can already support that if needed. And it is an advanced feature. |
| 11:24 | erikos | cms: yes, we should come to a decision, now |
| 11:24 | alsroot | garycmartin: +1 |
| 11:24 | cms | garycmartin: maybe, need to think about that |
| 11:25 | erikos: what do you think? tags or grid view? | |
| 11:26 | garycmartin | cms: another small topic. I'd like to suggest we remove the treeview title bars (on both Journal and Home list view). These are only in the new 0.85.x builds, but they don't provide much utility, eat space, and can leave the user in unexpected 'sort' modes. |
| 11:26 | tomeu | garycmartin++ |
| 11:26 | needs to leave now | |
| 11:27 | erikos | cms: I think, tags can be done more easily incrementally |
| 11:27 | cms | garycmartin: you mean the sort bar? |
| 11:27 | erikos | tomeu: not that you where here, yet :))) |
| 11:27 | cms | garycmartin: i should spend some time with it; i think it's inherently very useful |
| 11:27 | erikos | s/where/were |
| 11:27 | cms | tomeu: talk to you again next week? |
| 11:27 | garycmartin | cms: sort bar, yep. It's pretty useless to be honest, and confusing. |
| 11:28 | cms | gary: it shouldn't be useless if implemented correctly. let me take a closer look in the current build and get back to you |
| 11:28 | everyone, i have to leave also | |
| 11:28 | garycmartin | cms: only helps if we add a bunch of new columns (creation date, file size, activity type, etc, etc) and that is just bloat to the UI. |
| 11:28 | erikos | ok -------------- |
| 11:28 | decision *now* | |
| 11:29 | cms | i guess i'd vote for grid, if we think it can make it in |
| 11:29 | erikos | is fine with that |
| 11:29 | garycmartin | cms: Thanks for making it, lots of useful things to consider. Will need to think back over what we actually solved todad ;-) |
| 11:29 | erikos | how about: |
| 11:29 | alsroot: does port his code to sugar | |
| 11:30 | cms | garycmartin: thanks, and yes, i agree. we should hold these meetings more often! |
| 11:30 | erikos | cms: you have a design iteration over the left items for the grid view |
| 11:30 | cms | erikos: left items? |
| 11:30 | erikos | cms: get back to use - ml |
| 11:30 | cms: the toolbar, I thought was not clear 100% | |
| 11:30 | garycmartin | cms: yes, more meetings! :-) I didn't even get through my list ;-p |
| 11:30 | cms | erikos: ah, yes |
| 11:30 | erikos: i'll work on it | |
| 11:31 | erikos | cms: awesome |
| 11:31 | alsroot: sounds good to you as well? | |
| 11:31 | alsroot | erikos: yup |
| 11:31 | cms | i'll send out an email to everyone probably tuesday evening |
| 11:31 | erikos | and we can meet on wednesday morning and talk over what we have landed |
| 11:31 | cms | with mockups |
| 11:31 | erikos | great |
| 11:31 | garycmartin | phew!.. |
| 11:31 | cms | erikos: sounds good. for me it would have to be very early wed morning, around 8am EST |
| 11:32 | but we can resolve the time later this week | |
| 11:32 | erikos | cms: no problem for me - as this is 14:00 for me |
| 11:32 | cms: nice | |
| 11:32 | cms | great--thanks everyone! |
| 11:32 | talk to you soon | |
| 11:32 | erikos | thanks very much everyone for taking the time |
| 11:32 | garycmartin | Thanks all! |
| 11:32 | cms | bye |
| 11:32 | erikos | ttyl |
| 11:32 | alsroot | erikos: what was conclusion for 1) -- I'm afraid I lost the track |
| 11:33 | erikos | alsroot: ok |
| 11:33 | alsroot: what you have in your screenshot is the way we go | |
| 11:33 | alsroot: the button with the palette | |
| 11:33 | alsroot: the 'chat' screenshot you posted today | |
| 11:34 | alsroot: we need to make the buttons left aligned in the toolbar, as well (share, keep...) | |
| 11:34 | alsroot: does that answer your question? | |
| 11:34 | alsroot | erikos: and what about tooltips for buttons w/ subbars? |
| 11:34 | garycmartin | alsroot: making sure the Activity palette name always matches the title input area ;-) |
| 11:35 | erikos | garycmartin: thanks for that important addition |
| 11:35 | garycmartin: we, technically, need to listen for the title change here | |
| 11:36 | garycmartin | erikos: yea, I know. makes it more complicate :-( (I would have been OK with the icon just being an incative label) |
| 11:36 | erikos | garycmartin: nah, is fine |
| 11:36 | alsroot: http://www.pygtk.org/pygtk2ref[…]et-tooltip-window | |
| 11:37 | alsroot | well, whats the way I should implement, button w/ label palette or inactive button? |
| 11:37 | erikos | alsroot: I guess we could see if we can position the tooltip here a bit better |
| 11:37 | alsroot: palette | |
| 11:37 | alsroot | ok |
| 11:37 | erikos | alsroot: button with palette |
| 11:38 | alsroot: but I am worried the tooltips, when trying to customize them will cause a lot of trouble :/ | |
| 11:39 | alsroot: personally, I think we can move the tooltips down on the importance list | |
| 11:39 | has to run now as wel | |
| 11:39 | alsroot | erikos: well, ok |
| 11:39 | erikos: dont forget say #endmeeting | |
| 11:39 | erikos | #enmeeting |
| 11:39 | garycmartin | erikos: tooltips, down improtance list +1 yea cms seemed to suggest if they didn't happen, it would not be the end of the world. |
| 11:39 | erikos | #endmeeting |
![http://people.sugarlabs.org/~a[…]/Chat-toolbar.png](http://people.sugarlabs.org/~alsroot/Chat-toolbar.png){kind=link}
![http://wiki.sugarlabs.org/go/F[…]rowse-toolbar.png](http://wiki.sugarlabs.org/go/File:Browse-toolbar.png){kind=link}
![http://wiki.sugarlabs.org/go/F[…]_tags_palette.png](http://wiki.sugarlabs.org/go/File:Journal_mockup_gary_tags_palette.png){kind=link}