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

#sugar-meeting, 2009-05-09

Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
10:14 cms tomeu, do you want to give us an overview of the issues being discussed?
10:14 tomeu cms: about the home view?
10:14 or all of them?
10:14 cms actually, i was thinking more of the topics for today
10:14 tomeu ok
10:15 so about the home view, http://dev.sugarlabs.org/ticket/806 is only about children deleting all activities
10:15 we should ask for feedback as well about the usefulness of favorites
10:15 cms the home view is a separate discussion, though the ticket points out an important defect
10:15 tomeu right
10:15 cms i agree that the similarity between the journal and list view is confusing
10:16 tomeu we cannot expect to be given a new design from olpc-sur, but they can point out aspects that are important and we overlooked
10:16 cms we need to find a solution to the problem, which i think will be more structural than visual
10:16 tomeu the fact that they feel compelled to delete stuff is also interesting
10:16 bemasc it's worth pointing out that 806 could be solved by simply disabling deletion from that menu
10:16 cms that's true--it is not something we wanted sugar to encourage
10:16 walterbender we also need to consider the idea of tags to bring different homeviews into play
10:16 tomeu yeah, may be good to find a short term solution for the 8.2.x branch
10:16 bemasc It would be a very simple patch to remove the "delete" menu item.
10:16 eben walterbender: yeah, we're working on those mockups.
10:16 garycmartin bemasc: yes and moving managment of bundles to the Journal where is should realy be.
10:17 tomeu but we should be using this feedback for the home view redesign we have already talked aobut
10:17 bemasc garycmartin: I mean this only as a way for Uruguay to quickly prevent this problem from spreading, not as a "design solution".
10:17 eben Right, if we always show activities in the Journal, then they can be managed from there.
10:17 The naming issue is another one which we've had a proposed solution to for a long time, and it just hasn't been done.
10:17 tomeu bemasc: dsd has find a solution for .py: making easier to reinstall the activities
10:18 using the activity updater (that we don't have in 0.84, btw)
10:18 cms eben: that makes sense--but it also removes activity management from home (that might be a good thing, but something to consider)
10:18 eben cms: Well, right. That was the point.
10:18 bemasc please, let's not discuss this now.  Tomeu, could you just list the topics on the agenda today?
10:18 eben Make the Journal the one-top "file manager", and leave Home as a place to launch stuff.
10:18 cms eben: i'm not sure it is the right solution, from an experiential standpoint
10:19 i agree--let's save this topic for the next meeting
10:19 it warrants more time than we have today
10:19 tomeu ok
10:20 Sayamindu's dictionary dialog. See http://www.mail-archive.com/su[…]org/msg04042.html
10:20 cms should we start with the clock activity?
10:20 eben, you mentioned you had mockups to share
10:20 tomeu was going in the order in http://wiki.sugarlabs.org/go/Design_Team/Meetings
10:20 cms sorry--that's fine
10:20 tomeu as you prefer
10:20 the disctionary is quite simple, just read that thread and see sayamindu's mockup
10:20 cms sure
10:20 eben can someone link to screenshots of the dictionary proposal? I can't play that movie file.
10:21 tomeu I can screenshot it
10:21 eben thanks
10:22 bemasc eben: you probably want http://www.xiph.org/quicktime/
10:22 tomeu http://shell.sugarlabs.org/~to[…]lla%20Firefox.png
10:23 this is the dialog
10:23 the sentence in blue is what was selected when the dialog was invoked
10:23 cms that looks pretty good
10:24 we can clean up the typography
10:24 walterbender It wasn't obvious to me why there is this one level of indirection: select a sentence and then a word
10:24 tomeu I guess sometimes that's what you want, sometimes not
10:24 bemasc walterbender: if you select only one word, then it should (and perhaps does) just show the definition.
10:24 tomeu maybe we could autoselect the first word?
10:24 eben walterbender: Yeah, it would be more direct if it just worked on word level.
10:25 cms eben: i agree
10:25 unmadindu does not like the sentence thing as well :)
10:25 bemasc There's no way to prevent the user from selecting more than one word
10:25 tomeu actually likes it ;)
10:25 walterbender eben: does it work with phrases too?
10:25 eben walterbender: few dictionaries have phrases, though.
10:25 yoshu I like the sentence thing
10:25 cms perhaps instead of being based on selection it is a toggle
10:25 eben cms: ?
10:25 unmadindu eben: uploaded to youtube: http://www.youtube.com/watch?v=wlnnw3haxds
10:25 cms to allow you to select only individual words
10:25 eben unmadindu: sweet, thanks
10:26 cms the issue seems to be how to invoke the dictionary, and currently it's based on selection
10:26 bemasc It has to be based on selection, because that is the X Selection mechanism is the only way the dictionary knows the text.
10:26 walterbender in any case, it is a great feature... I was picking nits
10:26 tomeu yeah, using the x selection is a very clean mechanism that we should keep, I think
10:26 eben I guess the sentence structure isn't a problem...it''s a fair solution for a selection of multiple words.
10:26 cms but it could also be a toggle button in the toolbar (similar to a help button), that brings up clarification for any word that is selected
10:26 eben If you select one, it behaves the "simple" way.
10:26 tomeu that makes no need to implement anything in the activity level
10:27 cms well--
10:27 walterbender maybe just define all the words selected?
10:27 cms i think i agree with walter and eben though, that it doesn't seem intuitive to parse an entire selection
10:27 tomeu cms: because of the implementation, it should be a global action, so not triggered from the activity window
10:27 eben cms: Toolbar is one option. A persistent device is another.
10:27 tomeu if it's in the activity, then each activity that wishes to benefit from it needs to implement something
10:27 cms it's usually a single word you are looking for clarification on
10:27 eben It would be nice if it "just worked" for all activities.
10:28 tomeu something in the frame would be better
10:28 garycmartin unmadindu: If you spell check a selection from a view source window (hey perhaps a python term dictionary could go in there as well ;-) ) do the modal dialogues conflict?
10:28 eben Right.
10:28 bemasc cms: if you select a single word, then there is no problem.
10:28 tomeu if it's a global action such as view source, it will just work for all activities
10:28 I think that's very important
10:28 unmadindu garycmartin: good catch - I think they would. I'll have to check :)
10:28 cms bemasc: that's true, but it seems potentially confusing to have more functionality than that
10:28 eben cms: Not necessarily.
10:28 walterbender if it is a python keyword or module name...
10:28 cms bemasc: i.e., i don't know a case in which one would actually want to select an entire sentence
10:28 eben cms: What would it do with a multiple word selection?
10:28 tomeu walterbender had good ideas about how to use the frame instead of a modal dialog
10:29 eben Just refuse to work? Pick the first word?
10:29 bemasc cms: inter-language dictionary, trying to work out a sentence in a foreign language.
10:29 cms eben: right, but why would you need to select multiple words?
10:29 tomeu should we move to the next topic? everybody seems to be well aware of the problem now
10:29 eben While the sentence structure is a little unfamiliar, it's actually an interesting solution, and could work if it looked a little better than blue hyperlinks. :)
10:29 bemasc I do think it needs an indication for which word is currently being viewed.
10:29 cms eben: i need to give it some more though
10:30 eben cms: Who cares? If you do happen to, isn't this a reasonable thing to do with them?
10:30 bemasc and I do think it should default to the first word if multiple are selected.
10:30 eben If you just select one word, as most people will, it will behave exactly as we'd expect.
10:30 cms eben: i don't know--i think it may be more intuitive to restrict it
10:30 eben bemasc: Yes, that's the other logical  option, I think.
10:30 unmadindu maybe we can use back/forward buttons to switch between words ??
10:31 cms the implication for making a selection is translation
10:31 whereas dictionary does seem to apply more to individual words
10:31 eben Where does the dictionary content come from? Can we rich-text style it? This version looks a little overwhelming because it's all plain text with no spacing...
10:31 cms maybe if we had a built-in translation functionality...?
10:31 unmadindu eben: we can (to some extent at least)
10:32 cms: +1 on that - I'll look if there are tools which can be used in the backend to do that
10:32 eben cms: Yes, that would also be fantastic. And it could be the same feature, actually...
10:32 tomeu should we move on?
10:33 eben tomeu: I'm not sure we decided where this should live...
10:33 cms tomeu: sure
10:33 bemasc machine translation is not easy. The only way to do it is basically to use Google.
10:33 cms bemasc: that would be fine, i think...
10:33 tomeu eben: I thought we were just giving a quick overview of all issues
10:33 eben Should it be a shortcut? A Frame device? If it's a Frame device, can I open it without a selection and just type in a word to look up? (I'd say yes.)
10:33 cms bemasc: it would still be helpful, and would extend the dictionary functionality
10:33 bemasc So, I floated an idea on the list: that these things should live in the Frame.
10:33 eben tomeu: Oh...ok, that's fine.
10:34 bemasc: Yeah, that's my inclination as well.
10:34 tomeu so, mtd_ has proposed adding an icon in the frame and we have asked people in opc-sur about it
10:34 cms eben: where do you see it in the frame? i have my doubts...
10:34 tomeu s/icon/clock
10:34 bemasc Right, the problem is: it's not a "device".
10:34 eben cms: In the bottom edge, next to "speak text" and other similar tools.
10:34 cms eben: doesn't this make more sense in the toolbars?
10:34 cahalan for a dictionary or a clock?
10:34 tomeu as the dictionary works on a text selection, it could be in the clipboard
10:35 cahalan: I think we are still in the dic
10:35 eben cms: Not really....then it's not consistent across all activities.
10:35 cms tomeu: that's a great idea
10:35 tomeu eben: do you know how text selections work in X?
10:35 bemasc Maybe it could go on the bottom bar, but starting on the left side?
10:35 tomeu you will need to know that stuff to make a design that involves the x selection and the clipboard
10:35 cms it would make sense to combine with the clipboard
10:35 walterbender aside: we should think about how to interface all of this with accessibility tools as well
10:36 eben cms: I don't think I agree.
10:36 cms eben: why not?
10:36 tomeu walterbender: yeah, I'm curious about xo 662
10:36 eben That confuses the purpose of the left edge...it's just a storage space. If you start adding several custom features, it takes away space from the clipboard and you won't know what's a clipping and what's a button.
10:36 tomeu need to look at it
10:36 cahalan eben: the x selection and clipboard is more compatible
10:37 tomeu eben: read about x selections and you may come with a solution that you like
10:37 eben I think the dictionary is more like a persistent tool, like speech, or a clock, etc.
10:37 cms eben: i see your point.
10:37 unmadindu had to shut the clipboard up temporarily to make the dictionary work
10:37 tomeu unmadindu: I think we can fix that
10:37 cms eben: so you see it more as a device
10:37 garycmartin eben: +1, for a persistant tool.
10:38 eben cahalan: I understand the technical similarities that go with acting on a selection, but looking a word up in the dictionary has nothing to do with storing it in a temp location for later use.
10:38 cahalan eben: "later use" == "look it up"
10:38 bemasc X makes a very hard distinction between the clipboard and the selection.
10:38 eben cahalan: No, "look it up" == "take an immediate action on this selection, and then I'm done with it"
10:38 cms eben, i think i agree, though one could perhaps contemplate extending the clipboard section to include other tools for working with text
10:38 eben the "later use" storage is the brain of the child learning the meaning of the word. :)
10:39 cahalan bemasc: right, any sane code will shove data into both to mitigate the disaster :-(
10:39 eben cms: But the clipboard isn't just about text...
10:39 cms but perhaps it's cleaner to keep as a device in the frame (even though the metaphor doesn't quite work)
10:39 bemasc cms: for that reason, I think the "tools" should grow from the left side of the bottom edge, and the "devices" should grow from the right side.
10:39 cms eben: right, but not sure that really matters
10:40 bemasc This places them in proximity to the clipboard, and also creates a (soft) distinction to indicate that they are of slightly different types.
10:40 cms bemasc: i do think we need to stick to the organizational methods we currently have in the frame
10:40 bemasc: worried it would become too cluttered if we started running tools from both sides
10:41 cahalan eben: it makes more sense if you consider the way copy-and-paste works in the traditional X UI. The "copy" operation is merely a mouse movement to select the text. There is no ^C.
10:41 tomeu people, it's 40 minutes since we started
10:41 eben cms: Yeah, and then what happens when they meet? Heh.
10:41 tomeu we are not going to deal with everything
10:41 eben OK, let's move on.
10:41 bemasc eben: the same thing that would happen if the number of devices exceeds the available space.
10:41 tomeu ok, clock
10:42 eben Let me paste links to my (rough) mockups.
10:42 tomeu martin has proposed adding a clock to the frame and we have asked people in olpc-sur about it
10:42 olpc-sur is our main way to get feedback about sugar, specially about 0.82
10:42 cahalan should provide seconds during mouse hover
10:42 eben https://dl.getdropbox.com/u/10[…]digital_basic.jpg
10:42 https://dl.getdropbox.com/u/10[…]ital_settings.jpg
10:43 cms eben: suggestion: can't we use the analog clock icon instead?
10:43 eben https://dl.getdropbox.com/u/10[…]ital_calendar.jpg
10:43 https://dl.getdropbox.com/u/10[…]/clock_analog.jpg
10:43 tomeu last proposal from mtd here: http://www.mail-archive.com/su[…]org/msg03996.html
10:43 cahalan maybe more... default: HH:MM  With mouse hover: HH:MM:SS.S
10:43 cms the analog clock looks good
10:43 eben Yeah, I included an analog mockup. I like it the best in terms of appearance in the frame, but it's not the most easily readable. That might be OK.
10:44 cms eben: i think that's fine, as you can rollover and see the exact time
10:44 eben We could simply show digital on hover, as in the analog mockup, and omit the digital option in the icon...
10:44 bemasc I really don't understand the desire for analog clocks
10:44 garycmartin cms: yep + one for analogue, I was thinking to let mtd do all the hard word and add an analoge mode myself later :-)
10:44 cahalan cms: analog clocks are slowly passing into history, they vary across culture, etc.
10:44 bemasc Outside the first world, analog clocks are dead
10:44 tomeu do you want to hear what said the teachers in .uy about the clock?
10:45 eben tomeu: please
10:45 cms i'm partial to the analog clock because it works within the square icon module (and also looks more elegant!)
10:45 bemasc cms: form over function is always a bad idea.
10:45 yoshu analog clock fits nicely with the ui
10:45 tomeu one person said that there should be no clock widget, but a clock activity that teaches various topics about time
10:45 cms bemasc: not always... ;)
10:45 tomeu the rest of the people said that they wanted a clock in the inferior frame
10:45 cms tomeu: that isn't a bad idda
10:46 tomeu several also requested it to display the date
10:46 cms i think generally this makes sense in the frame, as a "device"
10:46 tomeu one person requested it to be analog as well, in order to teach analog clocks, but I think that could be in the Clock activity (we already have it)
10:46 eben cms: Yeah, I agree. (That doesn't preclude a clock activity, which we already have in fact)
10:47 tomeu we have also been asked for a chronometer
10:47 garycmartin I was always told reading analogue face helped with other math concepts.
10:47 cms eben: i think whether digital or analog, the icon needs to fit within the square module
10:47 tomeu so kids can measure the time it takes to them to do something in some activity
10:47 bemasc tomeu: There's already a stopwatch activity.
10:47 eben cms: I agree.
10:47 It's a little tight, but I think it can work.
10:47 tomeu though that perhaps should be integrated in each activity
10:47 walterbender eben: why doesn't a multiple of the 75x75 work?
10:47 tomeu bemasc: we should tell them
10:47 bemasc oh
10:47 cms eben: you could stack the digits...?
10:47 tomeu bemasc: maybe the activity team should adopt it if it's orphaned
10:48 cahalan Analog still needs 12-hour and 24-hour variants. I believe it also needs a 6-hour variant somewhere in SE Asia.
10:48 eben walterbender: because then we give device developers freedom to make arbitrarily large devices. The grid is a rule that's never been broken to date, and it would be nice to keep things simple.
10:48 bemasc tomeu: I wrote it.  It works.
10:48 tomeu bemasc: ok, we need to publicicze it
10:48 cms walter: i think a larger size starts to suggest that some activities may be more "important" than others, due to larger scale
10:48 eben cms: I tried digit stacking. Looked really weird.
10:49 tomeu eben: I think your proposal matches very well what's being asked
10:49 cms eben: i'm still in favor of analog... especially since the exact time is visible on rollover.
10:49 cahalan 75x75 can fit HH:MM just fine
10:49 bemasc If you're going to provide an analog clock, you must at least make it optional
10:49 eben cms: I'm in favor of analog by default, with a digital (still 75x75 px) option
10:49 walterbender eben: then a device for hours and a separate device for minutes?
10:49 cms https://dl.getdropbox.com/u/10[…]/clock_analog.jpg looks great
10:49 bemasc cms: yes, it looks great, but you can't tell what time it is.
10:49 eben walterbender: he heh
10:50 cms bemasc: i think you can!
10:50 bemasc cms: are you 9 years old?
10:50 eben cms: I think we have to have a digital option.
10:50 cahalan cms: oh that is truly awful; there are no numbers!
10:51 cms eben: not sure we do
10:51 tomeu we should take into account that frame devices are very easily modified, so we don't need to reach a solution that pleases everybody around the world: each deployer can put the implementation they want
10:51 cms eben: again, it's in the rollover menu
10:51 cahalan cms: an analog clock requires lots of numbers. There is not enough room for them.
10:51 yoshu I think there should be a digital option - I like analog, but it might be hard to read for some
10:51 cms cahalan: what's wrong with eben's mockup?
10:51 eben cms: he's arguing that because there are no numbers....not even tick marks...it's hard to read.
10:52 cahalan cms: I'm looking at https://dl.getdropbox.com/u/10[…]/clock_analog.jpg which has no numbers.
10:52 cms eben: right, i know, but i don't think it's that hard to read
10:52 eben Which is true. If you're not familiar with reading analog clocks, they are hard to read without at least an indication of the hours, if not the numbers themselves.
10:52 bemasc for children, they're hard to read even with complete numbering
10:52 eben cms: But you've been reading analog clocks for 25 years.
10:52 bemasc even for adults they're significantly harder to read
10:53 cms ok, as long as we stick with 75x75
10:53 bemasc I guarantee that any adult takes at least 3 times as long to tell you the time from an analog clock
10:53 5 times as long if there aren't any numbers
10:53 eben I switched back to an analog watch a couple years ago, and my face has no numbers or tick marks....it took some time to adjust to, actually.
10:53 bemasc I make this guarantee even for eben, who apparently wears such a watch every day.
10:53 tomeu 53 minutes since the start of the meeting, should we move on (the biggest topics are yet to come)?
10:53 cahalan bemasc: probably half a minute for me, since I've never owned an analog clock
10:54 cms we can split hairs over which is better (functionality vs elegance)
10:54 tomeu: let's move on
10:54 walterbender eben: I was serious about two devices: hours & minutes
10:54 eben cms: I think making it an option gets us past it.
10:54 We can make elegant default if we want to...
10:54 cms eben: agreed
10:54 cahalan walterbender: they both fit in 75x75
10:54 walterbender cahalan: 75x75 each
10:55 tomeu ok
10:55 bemasc I don't think enormous numbers are necessary.  All the other text in the UI is quite small
10:55 cahalan walterbender: not needed; you can fit into 75x75 without making the font too small
10:55 eben OK, I'll try to refine the mockup and post a more final version to the list.
10:55 cms thanks eben!
10:55 tomeu eben: tell me when you want feedback from olpc-sur
10:55 cahalan 15x30 characters
10:55 eben The small clock icon uses the "standard" system font size, btw.
10:56 tomeu jameson is proposing changing the current rules for accelerators, and making them more pervasive: http://wiki.sugarlabs.org/go/D[…]s#Keyboard_Action
10:56 IMO, accelerators will make sugar much more usable for a considerable portion of our users
10:56 walterbender tomeu: for a growing portion of our users: the non-XO community
10:57 tomeu walterbender: true
10:57 I haven't thought much about jameson's proposal, but really think we need to move forward regarding this issue
10:58 bemasc I don't think homunq means his proposal to be too strict.  It's more of a starting point for discussion.
10:58 tomeu jameson has proposed a rule to decide which accelerator modifiers are used and also proposed a way to make accelerators more discoverable
10:58 eben I like the overlay idea...but I think it should be on a short delay (so it doesn't flash if you already know your shortcuts), and I don't like the idea of flashing on button press...
10:58 cms can somebody explain this to me
10:58 tomeu he proposes that when a modifier key such as <alt> is pressed, an overlay with the acclerator keys appear on each control that is activatable
10:59 bemasc cms: there are two, mostly-independent components.
10:59 cms this is a way for assigning keyboard shortcuts?
10:59 eben Most of his basic ideas for ctrl, alt, and shift match our design intentions (there's a ticket somewhere spec'ing this).
10:59 cms: no...it's a way to discover them.
10:59 bemasc 1. A standard for assigning shortcuts, dividing up ctrl, alt, etc.
10:59 eben A cheat sheet which appears overlaid on the UI when you hold a modifier key down.
10:59 cms i see
10:59 bemasc 2. A visual display so that when you press Ctrl, all the available Ctrl+* shortcuts appear.
11:00 tomeu likes a lot the overlay idea, but is worried it may be hard to find a way that works fine without lots of added custom code
11:00 cahalan it better not mess with Terminal
11:00 cms that's nice. i think the visuals need refinement, but the general idea is great
11:01 walterbender again, we should probably get an accessibility review
11:01 cms do the left and right panels also appear only when i press CTRL?
11:01 eben cms: Oh, where'd you finda  mockup?
11:01 bemasc cms: that's not a mockup of this
11:01 cms ah
11:01 that explains my confusion
11:02 there is no mockup?
11:02 bemasc there is no mockup
11:02 eben oh, right...that's home stuff. unrelated.
11:02 tomeu walterbender: we should get in contact with the people doing accessibility work in gnome (mostly sun)
11:02 garycmartin I think this proposal need breaking down into individual items, it hits way to many things all over the place so I find it hard to agree with.
11:02 eben Imagine a bunch of little rounded rectangles with letters in them, superimposed over the corresponding buttons in the UI when holding down a modifier key.
11:02 cms eben: what are you looking at?
11:02 eben cms: I'm not.
11:03 I'm painting you a mental image. :)
11:03 cms eben: i'm not following this discussion then
11:03 tomeu garycmartin+++++
11:03 cms so the proposal is for key commands to appear on the view when you hit ctrl--that sounds like a good idea
11:03 tomeu I'm finding very hard to follow people's proposals
11:03 bemasc so you start an Activity, and you open the edit toolbar
11:03 but you've forgotten the shortcuts for copy and paste
11:04 so you hold down Ctrl
11:04 and "Ctrl+V" appears in a box on top of the Paste button.
11:04 eben bemasc: I'd say just the [v], but yeah.
11:04 cms bemasc: that sounds good
11:04 eben (since you're already holding control)
11:04 garycmartin bemasc: for this use, the hover accelerators already provide this feedback.
11:05 bemasc garycmartin: right.  This is a faster-than-hover optimization.
11:05 cms garycmartin: i think this could be an added benefit, in addition to hover states
11:05 garycmartin bemasc: seems a small gain for what seems a lot of work.
11:05 bemasc garycmartin: homunq is already doing the work.
11:06 tomeu bemasc: homunq is doing the implementation, that's a small part of all the work
11:06 but anyway, I think the overlay is a superior way to give feedback about the accelerators than the tooltip
11:07 but it would be already much much better than what we have now if all accelerators were set and showing in the tooltip
11:07 eben tomeu: Right...we should make that first priority.
11:07 garycmartin tomeu: +1
11:07 tomeu so maybe the overlay can be seen as an optimization that can come later
11:07 eben Getting a consistent ruleset for assigning shortcuts, and making them ubiquitous, is first order.
11:07 tomeu yeah
11:08 eben Optimizing their discoverability seems second to making them available and consistent.
11:08 bemasc eben: I do not believe this is likely to be accomplished, especially because we are trying to support a wide variety of different keyboards.
11:08 tomeu we have already stopped doing critical things because we couldn't agree on the advanced, less useful stuff
11:08 bemasc Thankfully, we can proceed in parallel here.
11:08 cms tomeu: do we have any other list items?
11:08 tomeu cms: only print left
11:08 http://wiki.sugarlabs.org/go/D[…]m/Meetings#Topics
11:08 cms maybe we should move on to print--walter has to leave soon
11:08 tomeu see the links there about printing
11:08 as well
11:09 we have a gsoc student that is going to work on printing, and several members of the community that are enthusiastic about helping out
11:09 on the other side, teachers in .uy have said that printing won't be very useful in thier schools
11:09 bemasc We have already debated this design to death, IMHO.
11:09 cms a while ago, we had talked about printers appearing in the neighborhood, as networked devices
11:09 similar to access points
11:10 tomeu bemasc: to be true, I have never understood any of the proposals, I think we should get better at explaining our proposals
11:10 not everybody can put so much energy on these debates
11:10 cms eben: do we have any of those early mockups on the wiki?
11:10 bemasc doesn't think any devices should appear in the neighborhood
11:11 cms bemasc: explain?
11:11 tomeu doesn't see printers appearing in the neighborhood as a critical part of the feature
11:11 bemasc cms: we don't have time for this discussion.  Basically, I think neighborhood, group, and home all need to be revised rather dramatically.
11:12 eben cms: I don't think that we do, but the idea is simple enough.
11:13 bemasc anyway, Vamsi is working diligently on this, and I think an iterative design process is probably best.
11:13 tomeu I'm more interested on what the user does when she wants to print, rather than how to find a printer
11:13 cms i think there is a larger discussion to be had, but given where we are currently, it makes sense that printers appear in neighborhood alongside people and access points
11:13 tomeu at least 80% of the time, the printer will be connected directly to the xo
11:14 cms: I doubt sugar will be used often in environments with network printers in at least the near future
11:14 cms i suppose one could print from the activity dialog, or from the printer dialog (it would print the in-focus activity)
11:14 eben cms: I think the neighborhood idea only makes sense if the printer is actually networked....if, for instance, the kid with the printer attached to his XO can allow others to print through him...
11:14 cahalan tomeu: right, sadly -- network printers are complicated and expensive
11:14 tomeu btw, teachers in .uy have noted that paper is part of the old way of doing things and that xos and internet access being ubiquitous make paper much less needed
11:14 bemasc The biggest problem we have here is a lack of feedback from actual users.
11:14 eben Like a mesh portal....a printer portal
11:15 cms eben, tomeu: i agree with that
11:15 if connected directly to the XO, it probably should appear in the frame as a device
11:15 bemasc My high school had networked laser printers in all the computer labs.  Is this common? I have no idea.
11:15 tomeu bemasc: we have had quite a bit of feedback in olpc-sur in the last days
11:15 I guess will be different in each country
11:15 eben cms: like an AP, it probably would anyway...
11:16 bemasc tries to subscribe to Sur again, after last attempt failed entirely.
11:16 cms eben: exactly
11:16 tomeu but for now, teachers have explained why printing won't work in their schools
11:16 eben So, then the proposal here, really, is to make the attached printer appear in the Frame as a device (makes perfect sense), but then how does one print to it?
11:16 cms ok, so if we assume that the printer appears as a device in the frame, one could either go to the printer dialog to print the in-focus activity, or accomplish the same thing from the activity toolbar
11:17 eben Drag'n'drop? A print option in the activity menu? both seem logical, but both are entirely different than the proposals that have been talked about recently on the list (I think)
11:17 cahalan eben: print button in the activity
11:17 tomeu I see why using the neighborhood to show printers is very appealing design-wise, but I think it won't be useful at all
11:17 cms cahalan: that's one solution--the other would be to print using the printer device in the frame
11:17 eben cahalan: Sure. I think of the activity menu and the activity toolbar as synonymous.
11:17 cms: Actually, that direction is kind of confusing to me....
11:17 cahalan cms: printer device in the frame sounds useful for managing print jobs, etc.
11:18 eben But maybe if the button reads "Print 'A picture of my house'" it would work.
11:18 It could actually just have a submenu for all of the open activities which support printing.
11:18 cms i think it's a question of which comes first--printing an activity, or selecting print from an activity. that's why there might be two parallel ways to accomplish the same thing
11:18 cahalan eben: well I **have** a print button
11:19 cms eben: right
11:19 cahalan: i think a print button should also exist
11:19 garycmartin eben: is the journal still keeping it's bottom tool bar for showing sd and usb cards? Could the printer appear there, then you just transfer a pdf into it from the journal?
11:19 eben Yeah, definitely not arguing against a print button in each activity.
11:20 garycmartin: No, that's the device edge of the Frame, now.
11:20 garycmartin eben: understood, I thought so.
11:20 tomeu having a print button in each activity fits the gnome way, btw. and if we use that infrastructure instead of inventing our own, we'll be better off
11:20 walterbender is still in favor of pushing all this to the realm of the Journal...
11:20 eben Which is why the bottom edge of the Frame makes sense for the printer too....of course...the Frame is available from the Journal, so you can still do what you say.
11:21 bemasc I think this sort of interactive design is best accomplished in a tight loop.
11:21 eben walterbender: could you describe how that would work?
11:21 tomeu walterbender: the problem I see with that is that it's harder that way to get the activities to participate in how the content is formatted for printing
11:21 cahalan walterbender: the print button can certainly put something in the journal, via a command (/usr/bin/lpr for example) that the activity can invoke
11:21 bemasc My main opinion here is: there's a tremendous amount of work needed to cover all use cases with printing.
11:22 Vamsi is going to do a piece of it, and I think we should observe the result and build from there.
11:22 walterbender However activities choose to format things, let the journal be the place where we manage the queue...
11:23 bemasc walterbender: that depends on whether you see print jobs as creations or ephemera.
11:23 walterbender bemasc: you are worried about journal spam?
11:23 bemasc walterbender: right.
11:23 cahalan walterbender: That works for me, as long as there is a command to stuff my postscript into the journal. Of course, then some poor kid will need to actually find it in his journal.
11:24 cms using the journal to track print jobs makes sense
11:24 walterbender cahalan: at some level each activity needs to make its own choices about how to export for printing...
11:24 tomeu bemasc: I'm ok with taking a progressive approach, but if we can help telling what's the approach that will bring the biggest benefit, now is the best moment
11:24 cahalan bemasc: print jobs **being** spam, or being lost among spam? (IMHO, both are very true)
11:25 bemasc cahalan: the first, though I agree on both counts.
11:25 walterbender cahalan: but we'd support some basics, including print screen
11:25 eben cms: I think that statement negates having print device in the frame
11:25 walterbender cahalan: there is not much spam in the Journal these days.
11:25 bemasc I don't think the Journal is the place to "Track print jobs".
11:26 cms eben: couldn't the journal simply track your print jobs, in addition to having the device in the frame?
11:26 eben bemasc: Well, it depends. If every print job results in a PDF first, and then also a physical document, it could work...
11:26 cms don't forget that the purpose of the journal is to keep track of your interactions with the system
11:26 bemasc If we an actions/objects split, then a "I printed this thing" action would seem reasonable.
11:26 walterbender bemasc: I think it is the place for activities to put things and those things might want to be printed...
11:26 eben cms: Yes, but until we have an "actions" view, we shouldn't overdo it.
11:26 bemasc eben: what if you're printing a PDF!
11:26 walterbender maybe in addition to resume, there is print
11:26 cms bemasc: agreed, that would be ideal
11:26 eben If the print job creates a document (like a PDF), it works; if not, what good is it in the current design?
11:27 cms eben: maybe we should start incorporating actions already--it wouldn't hurt
11:27 eben bemasc: Heh. Good question. hard link. ;)
11:27 cms: easier said than done.
11:27 cms eben: well, for now they could be visually differentiated
11:27 bemasc eben: what if you're printing page 3 of a PDF? Now you create a new PDF object in the journal for that page?  This seems... non-ideal.
11:28 cms eben: and we could implement a way to filter them from the view if necessary
11:28 eben bemasc: hmm, true.
11:28 cms: It seems like that might be over-engineering things for this one use case.
11:29 cms bemasc: it's really more of a reference, but would allow you to invoke the same print job again in the future
11:29 cahalan Printing sounds really painful for XO users. How many mouse clicks are we up to now?
11:29 bemasc There are about a million different use cases here.  We're not going to settle it now.
11:29 cms eben: it's setting a precedent for the way other activities/tools could behave
11:29 cahalan: i think we're still taking about having a simple button in the activity toolbar/activity menu
11:30 bemasc From Activities that can generate their own postscript to activities that have no knowledge of printing.  From usb printers that are attached to the laptop, to networked printers that live behind a server with a moderated (or rate-limited) queue...
11:30 cms the limitation for actions in the journal should be that they have to be invoked by the user
11:30 cahalan cms: OK, one click? (the norm for Tux Paint on Linux, Windows, or MacOS X)
11:30 eben bemasc: If we could pick a simple base case to get working, and then extend that later, that would be good.
11:30 cms cahalan: one click if there is only one printer connected, yeah
11:30 cahalan ah, it's 2 -- still not bad
11:31 eben cahalan: 3...another to say "go"
11:31 bemasc vamsi picked the naive activity + moderated server print queue case.  (He did so with a lot of advice from the list.)
11:31 cms eben: couldn't we simplify that to one click?
11:32 eben cms: if there is one printer, and we don't want to support print options, yes.
11:32 walterbender it would be one click from the Jorunal...
11:32 cahalan walterbender: switching to the journal counts, as does everything before that
11:32 cms eben: clicking the icon in the toolbar would simply print, while options could be available in the hover menu
11:32 eben I could also see having a print button in the Journal, which sent the selected Journal entry to the printer...
11:32 cahalan walterbender: switching back counts too
11:33 eben But can we even print without an activity being open to handle it?
11:33 walterbender eben: yes
11:33 tomeu bemasc: my favorite proposal is adding a print to PDF and print to printer button to each activity and perhaps as well sending a journal entry to the printer queue. I think that covers decently most of the use cases and is very simple to implement
11:33 walterbender cahalan: I think the model of printing you are espousing is not realistic in a classroom...
11:33 eben cahalan: depends on your context. If it's already open, it's easier from the activity. If it's not, printing from the Journal (if we can) is much faster.
11:33 cms i do see the argument for printing from the journal... though it may not be the most intuitive to have to first switch to the journal
11:33 cahalan walterbender: it's used all the time in classrooms
11:33 bemasc I think we should close this discussion.  Without aa or iwikiwi, there's not much point.
11:34 walterbender kids aren't going to be printing all the time...
11:34 eben cms: I like it as an addition, not an alternative.
11:34 cms maybe the button in the activity toolbar could be visually aligned with "keep in journal" and provide a shortcut
11:34 bemasc Moreover, they've already considered it extensively, including the available programmer skills.
11:34 eben select an activity, click print. Could be in the Journal, could be the active activity...
11:34 tomeu bemasc: I think all the proposals should be discussed in the mailing list, this meeting is just to facilitate starting the process
11:34 walterbender cahalan: we heard as much from the teachers on the Sur list...
11:34 cms eben: yes, i agree. the function would exist in the journal, but activities could have a shortcut
11:34 cahalan walterbender: of course (they can be scolded, disconnected, rate limited, etc.)
11:34 cms eben: makes sense
11:35 tomeu eben, cms: I like that
11:35 cms eben: it could exist in the activity menu, then
11:35 simple, clear--and it works in all views
11:36 eben cms: that, too, yes.
11:36 activity menu/toolbar, and the Journal
11:36 cahalan walterbender: printing restrictions should be exactly that -- restrictions -- not ease-of-use hurdles
11:36 cms that seems like our solution
11:36 eben And is there still a device, to let you know that you have a printer attached? I would say yes.
11:37 cms i'm also in favor of recording print jobs in the journal--again, to prevent spam actions need to be limited to only those invoked by users, specifically
11:37 eben And it would be the place for status about printing...maybe the queue....and the place you get errors and such.
11:37 cms eben: yes, there should be a device
11:37 the printer device would be found in the frame
11:37 garycmartin eben: and if you have no printer setup/defined, none of the print cruft (buttons/menus) should show up any where.
11:37 eben cms: I don't think the action needs to go in the Journal unless it's a "print to PDF." I think we should save the "let's add actions" action-item as a separate topic.
11:38 cms garycmartin: that would be nice
11:38 eben garycmartin: Yes, that could be good.
11:38 tomeu cms, eben: I see an issue with being able to print from both the activity and the journal: different code is involved in the formatting of the document for printing
11:38 cms eben: ok, we can save this for the actions debate... ;_
11:38 ;)
11:39 eben cms: Yeah...I like the idea, but let's not confuse basic print support with journal actions...
11:39 cms tomeu: is it a time/resource issue?
11:39 we could probably prioritize one over the other to at least start with something
11:40 tomeu cms: the problem is that when we try to print a Write entry from the journal, it's not clear how the Write code will be involved in formatting it to pdf or ps
11:41 cms tomeu: but it still seems doable in the long-term?
11:41 tomeu cms: it's totally doable, but it may be hard to find a solution that can be implemented with enough quality given the resources available
11:41 cms we could start by supporting printing from the activity (the most intuitive use-case), and extend the capabilities later to include journal and other views
11:42 tomeu: if we start with printing from the activity, it wouldn't preclude us from addressing the other views later, right?
11:42 tomeu my favorite plan of action is to implement printing (PDF and to printer) in Write and Read, and allow sending PDFs from the journal to the printer
11:42 as a start
11:43 cms: sure not
11:43 eben tomeu: why just those activities?
11:43 tomeu eben: I think are the most likely to be used for printing
11:43 maybe imageviewer as well, it should be quite trivial
11:43 cms i think we could begin by focusing on only printing from activities
11:43 eben tomeu: I think clicking print should do all the work....shouldn't have to go to the Journal and push it along.
11:43 cms we could start with the activities most likely to be use for printing
11:43 tomeu eben: yeah, I think I explained bad myself
11:43 cahalan tomeu: paint programs are more likely IMHO, and Tux Paint already has printing support
11:44 cms i think read needs to be among them
11:44 tomeu cahalan: that fine
11:44 eben Can we setup a default for all activities? If the activity doesn't define it, just print a screenshot, for instance?
11:44 cms tomeu: i think your plan makes sense--and is a good starting point
11:44 cahalan tomeu: it's suitable for testing everything else
11:44 tomeu I would say starting with Read, Write, ImageViewer and Browse beucase I know their internals and I think it will be relatively easy to implement it
11:45 other activities are of course nice to have as well
11:45 eben tomeu: Oh, I parse your previous comment correctly now. :)
11:45 cms eben: we already have a print icon--is it shown anywhere in the current UI?
11:45 eben cms: no, but we have it, you're right.
11:45 tomeu eben: yeah, we could add generic code for printing the screenshot very easily
11:46 though don't know how useful that may be
11:46 eben It might be in the artwork repo already...not sure.
11:46 tomeu: might be nice for lots of activities that wouldn't bother otherwise...
11:46 cahalan plain text from the clipboard is a good one to support
11:46 eben In fact, it could just always be an option, in addition to "Print" and "Print to PDF", have "Print screenshot"?
11:46 tomeu eben: yeah, I like the idea of providing a base line when we can
11:47 cms sounds like we have a plan
11:47 eben tomeu: It seems like a good way to give some WYSIWYG printing options and give basic print support to all of Sugar.
11:48 cms tomeu: what do you need from the design team to get started?
11:48 eben Awesome.
11:48 bemasc So, Vamsi just finished the first step, making CUPS handle ODT (Write) documents directly
11:48 eben cms: Sounds like we need to make sure they have the icon, and maybe try out some printer device palettes to show printing status.
11:48 tomeu eben, cms: what we need is to establish a good communication between the new contributors and the design team
11:48 new contributors need to explain the ideas so the design team can understand what is proposed
11:48 bemasc So now CUPS can directly print PDF, PS, TXT, PNG, JPG, ODT, HTML...
11:49 cms tomeu: agreed. how can we best facilitate that?
11:49 tomeu and the design team needs to give design proposals so that contributors can understand them
11:49 cms: at this point, I would say to explain the proposed design in the mailing list
11:49 eben tomeu: Yes, definitely. Christian and I should get into the habit of putting more "short" mockup sequences (3-5 slides) in the design section of the wiki for things like this, perhaps.
11:49 tomeu cms, eben: I love your mockups, but sometimes we may need something dirtier but quicker
11:49 specially at the early stages of the discussions
11:50 cms ok
11:50 eben tomeu: Yeah, that sounds good. We can verbally describe our thoughts and then add mockups to support as we have the opportunity.
11:50 tomeu something I haven't liked is how the proposals of new features have had requirements and implementation all mixed up
11:50 that makes hard for non-technical people to contribute
11:50 well, it also made hard for me to understand what was proposed
11:51 vamsi sent some use cases that I think are good for printing
11:51 I think the design team can send proposals as a reply to that
11:51 cms so let's start by recording our thoughts (incl. mockups where necessary) on these issues
11:52 we'll put them in the design team section on the wiki and send out notifications to the mailing list
11:52 tomeu sounds cool
11:52 I see the design team wiki has already a section about proposals
11:53 homunq hi
11:53 tomeu see these use cases: http://lists.sugarlabs.org/arc[…]9-May/014164.html
11:53 cms thanks, that's helpful
11:53 eben Yeah...actually, I've been meaning to move that out of "Vision"....seems it should just be DesignTeam/Proposals...
11:53 tomeu sounds good
11:53 homunq: hi
11:53 one more thing we need is to ask contributors to read the HIG
11:53 cms i'm going to have to run
11:54 we addressed everything, tomeu?
11:54 tomeu so they understand the reasons for the current design, and also why consistency is important
11:54 cms: I think so. do we know how to move forward?
11:54 cms tomeu: believe so
11:54 eben Yeah, we need to revise the HIG, too....big chore.
11:54 There's lots of outdated material there, and it's also incomplete.
11:54 cms eben: let's talk offline when you have a chance
11:54 tomeu eben: well, it's already useful as is, I think
11:54 no need to block on that, I think
11:55 eben shoot. I've gotta run!
11:55 I have to be somehwere.
11:55 Bye all!
11:55 tomeu yeah, I need to go as well
11:55 garycmartin bye!
11:55 cms #endmeeting

Index | Today     Channels | Search | Join

Powered by ilbot/Modified.
Webmaster