Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting, 2009-08-16

Index | Today | Next day »     Channels | Search | Join

All times shown according to UTC.

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

Index | Today | Next day »     Channels | Search | Join

Powered by ilbot/Modified.
Webmaster