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

#sugar-meeting, 2008-12-04

Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
12:11 _bernie #TOPIC eBook reader requirements (chr__)
12:11 chr__ Bernie, can you run the show.  I have never run a chat based meeting.
12:11 _bernie Chris, would you like to introduce yourself and OLE?
12:11 #topic eBook reader requirements (chr__)
12:12 chr__ sure
12:12 My name is Chris Rowe and I work for Open Learning Exchange
12:12 manugupta chr__: wonderful.
12:12 chr__ http://ole.org
12:12 _bernie meeting: #topic eBook reader requirements (chr__)
12:12 bah ok
12:13 chr__ We are developing ITC based tools to help developing countries active universal basic education
12:14 our main goal is to provide free and open educational material through a world wide network of nation based centers
12:15 Rabi is the director of OLE Nepal, and we are looking for ways to support their work
12:16 In talking with Bryan he suggested that an ebook reader would be very helpful in allowing students to find and use the ebooks their teachers want them to read
12:16 Any questions so far?
12:16 anyone want more detail, or should we more on?
12:17 tomeu chr__: I guess it can be said later, but I wonder if you want a solution that assumes a server is accessible, or which kind of disconnected mode you want
12:18 manugupta chr__: sounds interesting, please continue. Are we looking for an e-book reader, or an off-line search engine for e-books?
12:18 chr__ Bryan suggested it would just need to read from the local file system to start with
12:18 tomeu ok
12:18 chr__ the idea is "an iTunes for ebooks"
12:19 so people can look through their local library, find something they want to read and ready it.
12:19 bemasc chr__: The Journal is very much like iTunes already.  It would be easy to make the Journal show a list of all locally available ebooks.
12:19 chr__ yes, we have talked about using the journal interface
12:20 eben I'm not sure that wrapping the "library" and the "book" into the same interface is the right course in Sugar.  But the two ideas both have merit.
12:20 chr__ at Sugarcamp it was unclear if we wanted to mix content you might use someday into the Journal
12:20 bemasc chr__: the harder problem turns out to be the actual viewer software.  That's something we're really lacking.
12:20 eben And, inasmuch as the Journal is *only* local content, a Library activity which exposes that in addition to server (school) or other online content could be a good thing.
12:21 chr__ eben:  I don't think we have to wrap them, as long as it is easy to browse through several books before choosing one to read.
12:21 bemasc chr__: what do you mean by browse?
12:21 eben chr__: "wrap"?
12:22 I was questioning the need to have the browser and the reader be the same activity.
12:24 chr__ bemasc: by browse I mean look through the meta data, open a book, flip through the pages, close it, open another book, maybe mark a book as interesting to return to later.
12:25 eben: why did you question wrap? you said "I'm not sure that wrapping the "library" and the "book" into the same interface is the right course in Sugar." So I said "I don't think we have to wrap them, as long as it is easy to browse through several books before choosing one to read."
12:27 eben chr__: Ah, gotcha.
12:28 continue. :)
12:28 bemasc chr__: what you are describing is very much the idea of the Journal, but it's true that the current implementation is not ideal for this use case.
12:28 chr__ eben: I don't think they need to be the same activity as long as the user knows how to get back to the browse interface after reading a book, and it is easy enough to do so it feels like you can flip through several books until you find one you like
12:28 homunq thinks journal should have server mode as well as local mode
12:29 bemasc The Journal makes it easy to view all objects of a certain type (e.g. ebooks), filter them according to some criteria, view any notes about them, and select one to open.
12:29 eben disagrees with homunq, apart from server backups
12:29 chr__ RabiKarma: Can you let us know if we are on the right track for what the teachers and students in nepal are wanting?
12:29 bemasc Important things we lack are: display of typed metadata and fast opening.
12:30 homunq how can opening be fast if it's over the net? preload is not cheap.
12:30 bemasc By this I mean (1) if an ebook object has metadata "publisher=Scholastic", that is not displayed anywhere in the Journal UI.  You can't filter or sort by publisher.
12:30 eben I have designs for the former...I think there's some real power to be added to the detail pages in the Journal, with intelligently exposed metadata.  I'm not sure our Journal previews are sufficient for previewing a book, though.
12:30 bemasc homunq: we are speaking about local storage.
12:31 eben bemasc: I think you can currently search for it, but you're right...it would be awesome to have more control there.
12:32 bemasc and (2) If you open a book, you get a new activity instance, and that instance lives until you close it.  If you're a conscientious multitasker then this is perfect, but if you're not good at managing windows then you might forget to close all those other books.
12:32 Also, Activity startup is unfortunately slow, though a great deal of work is going on to make it faster.
12:32 chr__ I think exposing a server in future versions would be a good thing to keep in mind. Again, think the iTunes store, where you can find and download books to your computer.
12:33 bemasc chr__: This is also something that has been a goal of the Journal, but is generally further off.  However, see scott's work on networked Journal; prototypes of this exist.
12:33 chr__ RabiKarma: Are you still with us?
12:33 manugupta bemasc: it seems both local storage and the capability to share over the network.
12:33 eben bemasc: I still don't think the Journal covers the server/online need.
12:34 bemasc Ultimately, not everything should be pushed into the Journal, I suppose, and maybe finding books is something that should be separate.
12:34 RabiKarma chr__: just got back. catching up with the discussion
12:34 _bernie I think we're going into way too much detail of the UI and search engine for a preliminary meeting.
12:34 bemasc manugupta: this sentence no verb...
12:34 tomeu I would love a list of improvements to the journal that would make easier to browse and work with downloaded pdfs
12:34 eben bemasc: I think the Journal should be pretty decent at managing local books, but I wouldn't be opposed to a Library activity that a) revealed online content and b) did a better job via specialization.
12:34 _bernie Besides, one of the requirements for OLE (and OLE Nepal?) is that the reader works also on regular desktops.
12:34 tomeu well, to the journal and to browse and read
12:34 eben tomeu++
12:35 I think these are both good causes, honestly.
12:35 tomeu yeah, what eben said
12:35 chr__ eben: I also linked to the work on the browser download progress interface, which seems to be a Journal like interface for getting remote content.
12:36 OLE is currently working with a team to try and make a sugar friendly web based library interface.
12:36 eben _bernie: Not really....we're tying to tease out the forms the thing should take, at a high level.
12:36 One activity?  Two activities? Activity + Journal? Etc.
12:36 This is needed to focus on feature sets in the right places.
12:36 _bernie Have people gone through the links to prior art in the field?
12:36 http://sugarlabs.org/go/OLE/Me[…]Existing_Projects
12:37 eben: let's not say "activity", it's too bound to Sugar.  Ideally, this application should even work on Windows.
12:37 manugupta _bernie: yes. miro seems to be a good use-case.
12:38 eben _bernie: This is a /sugar/-meeting. :-P
12:38 _bernie manugupta: to me too. except it's super-heavyweight. we should find out what parts of it are, and if we can get rid of them.
12:38 eben: heh :)
12:39 RabiKarma here is the challenge for us in Nepal: We have created an electronic library that will house full text documents and books that kids can read
12:39 marcopg hey manugupta, nice to see your around ;)
12:39 manugupta _bernie: we would need to work around the media player code.
12:40 RabiKarma currently we have used flibbook to make the reading experience fun and interesting for the kids
12:40 manugupta marcopg: me too. how are you doing?
12:40 chr__ Nepal's Library http://www.pustakalaya.org/
12:40 marcopg manugupta: pretty good! just completely swamped as usual :)
12:40 RabiKarma however, they can read using flipbook when they are online
12:40 but when the kids go home, the do not have access to the school network
12:40 and hence cannot read these books "offline"
12:41 tomeu RabiKarma: is the online experience completely satisfactory?
12:41 RabiKarma unless they download the pdf version, which does not give them the nice reading experience
12:41 manugupta marcopg: as expected :-)
12:41 tomeu: we need to move in that direction.
12:41 RabiKarma tomeu: the online experience is much better than reading offline pdf
12:41 manugupta tomeu: on-line experience seems to be better, I agree.
12:42 tomeu ok
12:42 RabiKarma: can you list the issues in which offline pdfs are worst?
12:42 chr__ RabiKarma: can you link to the reader they are using. flipbook?
12:42 RabiKarma tomeu: have you had a chance to check out the elibrary?
12:42 http://www.pustakalaya.org/
12:43 click on the first button
12:43 tomeu ok, going there
12:43 RabiKarma then the fourth link on the next page
12:43 that will give you a list of books
12:43 click on any one of them
12:43 _bernie tomeu: do not let the nepali character scare you away :)
12:43 chr__ http://www.pustakalaya.org/Fli[…]:209/Default.html
12:43 RabiKarma you will see two formats
12:44 one is pdf, and one is flipbook
12:44 check both of them to see the difference
12:44 tomeu ok
12:44 _bernie: I think I'm starting to get used to it :p
12:44 bemasc doesn't have flash...
12:47 eben The interface is pretty nice.  Does this actually run decently on XOs?
12:47 caroline mchua_ are you here?
12:47 tomeu RabiKarma: kids use to click "actual size" after turning each page?
12:47 homunq it doesn't look as if too much heavy lifting is going on on the server side. Couldn't this run with a local server in a modified browse?
12:48 tomeu I find the default font size a bit too small on my 12" screen
12:48 RabiKarma there are a number of shortcomings in the flipbook as well
12:48 and we have not had a chance to get feedback from the schools regarding flipbook
12:49 we have noticed that it does not render very well on the XO's
12:49 tomeu I'm reading janak and the giraffe, in case it matters
12:49 RabiKarma but we are trying to see how we can improve upon this
12:49 but it gives you an idea of what we are seeking to do
12:49 tomeu RabiKarma: the read interface hasn't received much love, so there's definetely room to improvement
12:50 chr__ RabiKarma: Do the students use their XO's in book reader mode when reading?
12:50 tomeu but we would need concrete issues so we can propose concrete solutions
12:51 RabiKarma chr__: i don't think they do
12:51 chr__: again, it has only been about a month or so that the kids have access to the library
12:52 _bernie RabiKarma: yeah I also have seen hardly anyone using the XO in book reader mode. wonder why.
12:53 eben The 2-up design would work well for picture books (or mostly-picture books); I don't think it would work for mostly-text.
12:53 RabiKarma tomeu: One major issue is not finding ebook readers similar to flipbook that can be used offline
12:53 chr__ _bernie: one reason may be that the controls are not easy to use for changing pages when you are holding it.
12:53 RabiKarma _bernie: do you mean in Nepal?
12:54 eben Right; proper implementation of handheld mode hasn't been given to any activity yet, really.
12:54 bemasc Sugar is not usable in rotated ebook mode.  Let's not pretend otherwise.
12:54 eben That could really improve Read and Browse, I think.
12:54 RabiKarma _bernie: that could be because they do not have ebooks to read
12:54 chr__ eben: I was talking about the placement of the buttons on the XO
12:54 tomeu RabiKarma: the infrastructure below Read is much more powerful than it seems, we could do very cool stuff, similar to flipbook
12:54 eben chr__: Ah, yes....agreed they are far less then optimal!
12:54 tomeu RabiKarma: also, unmadindu is doing some cool stuff by embedding that same codebase inside Browse
12:55 but development takes time and we should prioritize modifications correctly
12:55 eben I think it could be reasonable usable for basic paging, rotated, but not much more.
12:55 tomeu there may be quick improvements that bring substantial advantages
12:56 eben It depends on frequency of page flips as to whether it's really useful, I think.
12:56 unmadindu eben: do you have any specs in mind (mockups/etc?). I can do one more set of weekend hacks if required
12:56 chr__ eben: I cant find a way to comfortably hold the XO in portrait and be able to press the buttons
12:57 bemasc chr__: flipping pages on a physical book isn't so easy either.  The idea is to make the use infrequent and obvious.
12:57 eben chr__: Right, you have to move your hand to press it, which is why frequency is an important factor.
12:58 I find holding it with the directional buttons down to be best, myself.
12:58 I can slide my right and over and press it with my thumb.
12:58 bemasc I'm not sure what our purpose is here.
12:59 eben unmadindu: I should try it out again and see what the current button mappings are, first. :)
12:59 unmadindu oh, ok :D
12:59 _bernie (sorry I was distracted for a while)
13:00 eben twofold, it seems:  1) figure out how to expose "books I could read" (on a server, or otherwise) in a useful way and 2) figure out how to improve the reader to make reading books pleasurable
13:00 _bernie chr__, RabiKarma: do you think the list of requirements for the "ideal" ebook reader is mostly correct from the OLE pov?
13:01 this list: http://sugarlabs.org/go/OLE/Meetings#Wanted
13:01 if not, we might want to discuss, then add/change some of the items
13:02 so the output of this meeting might be a clear agreement on what the ebook reader might look like
13:02 chr__ I think they are right on, but more than we need to start with
13:02 bemasc There's not enough detail.  We need to know precisely what's needed in the interaction design, and currently we don't know.
13:02 RabiKarma _bernie: ideally, yes
13:03 tomeu perhaps we should select the worst few issues, then propose solutions for those, then enter in detail in the chosen solution?
13:03 bemasc Also, I'd like to point out that the Kindle is highly regarded as an ebook reader in terms of interaction, but it only reads documents that have been explicitly reformatted for the Kindle.
13:04 unmadindu same with the Sony Reader
13:05 chr__ I think our default format should be pdf.
13:05 bemasc I don't think we will ever be able to take documents that were designed to printed at 8.5x11 and display them automatically on the XO.
13:05 I think our default format should be UTF-8 .txt and HTML
13:06 unmadindu thinks he can make a evince backend for text  
13:06 chr__ bemasc: How easy is it to convert pdf to those fromats. Most ebooks that I see are pdf.
13:06 bemasc chr__: impossible.
13:07 chr__: we have a real problem.  PDF represents whole pages in essentially image-like form.  Our screen is much smaller than a printed page.
13:07 We have resolved this the only way we can, by letting users zoom in and out, and pan around the page.  This is as it must be.
13:07 _bernie bemasc: for possible UI designs, I and many others (including Bryan Berry who's not here) proposed something along the line of Miro, Calibre, Akarok, Rhythmbox, iTunes... you get the idea.
13:08 unmadindu however, existing stuff, especially for places with non-latin scripts come as PDF, and we need to take care of those as well
13:08 bemasc _bernie: None of those are ebook viewers. You're going to have to be a lot more specific. Also, I see the actual viewer as much more difficult than the library.
13:09 We cannot afford to drop support for arbitrary PDFs, but we must accept that it will never be good.  Kindle doesn't do arbitrary PDF for exactly this reason.
13:09 manugupta bemasc: Kindle has its own format. AZW, right.
13:10 _bernie bemasc: well, in my mind, the "viewer" part where the media player normally is, needs to be replaced with a PDF/HTML reader component.
13:10 bemasc So in addition to improving support for PDF to the greatest degree possible, I think it's also important for us to draw up a spec of "how to format a book for the XO."
13:10 unmadindu +1
13:10 bemasc That spec could be PDF with a particular range of font sizes, page sizes, graphic DPI, etc.
13:10 _bernie bemasc: why not HTML?
13:11 PDF and the like are really printed matter in digital form... anachronistic.
13:11 bemasc I think HTML would be a great choice
13:11 tomeu html sounds like the best candidate for now to me
13:11 eben _bernie: you're arguing agiainst exactly what I was saying earlier, which is that I don't think that "Read" and "Library" are the same thing.
13:11 tomeu though we should try to invent new stuff
13:11 _bernie eben: me neither
13:11 eben I think you can embed a decent previewer, but I also think there might be a separate reader.
13:12 _bernie eben: I think a Read-like interface would be embedded inside Library, or come up when the user clicks books in Library.
13:12 eben well, let's not forget crossmark, then....that was an interesting exploration...
13:12 chr__ There are several e textbook formats that might be good to look at. wikibooks.org, cnx.org, ck12.org, and Ed was talking about at sugarcamp come to my mind right now.
13:12 _bernie eben: crossmark? do you have a link?
13:12 eben _bernie: I argue not.  I argue that you should read a book in Read, not in the Library, which is the browser.
13:12 tomeu ahem, I really meant "though we should _not_ try to invent new stuff"
13:14 _bernie eben: yes yes... I think we can knit both interfaces together with a component architecture ala ActiveX, KParts, Bonobo, etc.
13:14 eben I could be wrong, but I think the simplicity of a fullscreen, context (last read page) aware, activity is still a very good thing to have.
13:14 _bernie: I don't *want* them knitted together.
13:14 you're missing my point, I think.
13:14 tomeu _bernie: no need to do that fancy stuff, we have gtk widgets for both evince and mozilla
13:14 eben: we could use those as a preview, though
13:14 eben tomeu: Oh, of course.
13:14 tomeu even if we don't really knit the viewer inside the browser ;)
13:15 eben _bernie: http://wiki.laptop.org/go/Crossmark
13:15 _bernie tomeu: even better (but how do these add component-specific toolbars and menus to the frame application?)
13:15 eben: ok, I see your point. you want to keep the applications separate.
13:16 tomeu _bernie: well, toolbars in pygtk are a 5 minutes exercise
13:16 _bernie eben: it's an interesting alternative, I need some time to think about it.
13:16 tomeu as long as the functionality is already in the widget...
13:16 eben hmmm, spec seems to be missing.
13:16 We'd have to ping neuralis, I guess.
13:17 _bernie tomeu: the COM/OLE2/ActiveX crap was designed to let components hack the UI of their host transparently... but, yeah, we're just doing a book reader supporting 2-3 formats, not a Whatever Reader! :)
13:18 tomeu _bernie: giving a good integrated experience between the book browser and the book reader is the same problem as with songs and media player, text adventures and games, etc
13:18 _bernie: add opendoc to that
13:19 _bernie: many people have tried and failed, it should show that it's a hard game to play and may not be exactly what our users need
13:19 chr__ It seems like the current solution for Sugar is use Browse to find stuff and download it to the Journal, then use the Journal to see what you have and open it in Read. Is that right?
13:19 tomeu chr__: yes, though we know that it's not very satisfactory and would love to improve it
13:20 _bernie chr__: would such a solution be acceptable on OSX or Windows?  I mean, we do an online html applicatio nand let people read with their system pdf readers?
13:20 (but I guess windows still lacks a system pdf reader ;-)
13:21 eben chr__: I think a powerful library application can be built separate from a reader, yes.
13:21 chr__ So, I would recommend focusing on the simplest way to make it nicer.
13:21 eben: yes
13:21 eben Delicious Library on OSX is a great example.  It doesn't even have a reader....it's just an organizer.
13:22 homunq There are, in my view, two routes for library: Journal or Browse
13:22 eben Of course, Delicious is mostly (entirely?) about local content, but the idea is similar....present a users stuff in a really nice and convenient way.
13:22 homunq I would argue for Journal, but not strongly
13:22 eben homunq: I don't think we have to shove it into Browse...it could just be HTML if we wanted, but I think it could stand on its own.
13:22 homunq certainly not if we don't want to integrate a server mode ever.
13:23 eben And Journal still doesn't handle the "I want to find a book from the library of online content!" issue.
13:23 Though we should definitely move toward making Journal a bit more "delicious"
13:23 homunq eben: agreed. Another browse-like activity, I meant.
13:23 eben For those that don't know of what I speak: http://www.delicious-monster.com/
13:24 In fact, this is a *great* model for us...it looks like it is shared now...
13:24 chr__ I think we need a ebook finder app just so that things downloaded by it are put in a separate place from the students work. If there is another way to achieve this than we could just use Browse
13:24 eben you can see your friends libraries, as well as your own stuff, and this could conceivably represent the school server or other repos as well..
13:24 and it's not a reader....just a big library with nice previews.
13:25 chr__: I disagree, there....anything the student downloads should go into their Journal.
13:25 But then, only things they actually "check out" from the library need be downloaded.
13:25 Things the glance at needn't be.
13:26 homunq eben: why is journal not perfect for this? "stuff I've done
13:27 " is just one more shelf
13:27 and you generally look at only one shelf at a time,
13:27 eben homunq: The Journal is personal stuff.....the library is about a bigger collection, outside the XO.
13:28 homunq: Think of the Journal as the metaphor....it's not a portal....it's a record.
13:29 homunq eben: if my downloads are being mixed in with my creations, it needs to grow nontemporal browsing features anyway.
13:29 sorry. Do other people have an opinion as to whether the library should be journal or html?
13:29 eben homunq: that's a separate concern.  We all agree that the Journal needs some major help in terms of scalability, search, and browse.
13:30 chr__ The concept we have at OLE is that a student would be able to download all the "books" that a teacher has assigned for a course and be able to find them group together on their computer.
13:30 eben homunq: Journal or separate App, really...HTML is a detail.
13:30 homunq eben: granted
13:30 but probably the fastest
13:30 eben it could just as easily be XML, or an RSS feed, presented with nice GUI widgets.
13:31 tomeu chr__: hmm, autoexpanding a special marked zip file that contains those pdfs should be quite easy to do
13:31 homunq big picture, please
13:31 eben at any rate, form and content should be separate ;)
13:31 tomeu oh, wait, that's quite similar to the .xol stuff
13:31 homunq tomeu: a content bundle?
13:32 eben chr__: OK, so in another model, the teacher creates a shelf, or a section, of the library for her students...
13:32 they go there, and they can take out books as needed, or take them all at once.
13:32 chr__ eben: right
13:32 tomeu homunq: yeah
13:32 eben Once the kid takes it, it gets downloaded to the Journal and can be opened/resumed anytime.
13:33 chr__ eben: sounds good
13:33 homunq What are the actual steps from here to a good experience?
13:33 I think that one of them is poor multitasking habits
13:33 eben But the "bundle" could be on the server end...that is, the kid doesn't receive the bundle as a raw file...they get a shelf or similar in the Library, which they are told to navigate to, for instance.
13:33 homunq a modest proposal:
13:33 Read never opens two instances
13:34 eben Obviously one of the necessary steps is the "activity A launch activity B" problem.
13:34 homunq If you open another book, it saves out current state and then takes over the read instance.
13:34 eben checking out a book should download it and open it in a suitable Reader. (or at least offer the option to do so)
13:34 homunq: I don't think that's a good idea.  That prevents cross referencing entirely.
13:35 homunq if it is faster on average?
13:35 I mean, the cross referencing can still be done, switching back and forth using journal instead of frame.
13:35 eben I think the multitasking issue is a general problem for Sugar to be better about, but not a blocker for this.
13:36 If we can make a) finding a book b) downloading a book c) reading a book rock, we're doing great!
13:36 Then we can pluralize each step ("books") and make that rock too.
13:37 chr__ Is there a way to tag downloaded files as ebooks?
13:37 eben a) and b) probably come relatively easily for plural books, since the purpose of the library is to make browsing collections easy.
13:37 chr__: Well, depends on what you mean.
13:37 You can certainly tag them anything you want and/or add metadata of any kind.
13:37 homunq and they already have a file type
13:37 eben Of course, we currently just treat objects by mime-type
13:38 homunq (favorite searches in journal)
13:38 eben If you're asking "how can we tag a book as a book, regardless of it's format?", then the answer is "just do it" :)
13:39 But yes, the Journal "what" filter is by mime-type
13:40 bemasc I think making the "what filter" smarter than just mime-type would be a good start.
13:40 chr__ I would argue that we should create a Library Activity that is just a broswer and but that any file downloaded from the Library gets a special tag that can be filtered in the Journal. That way we can access all the existing web based digital libraries or build our own.
13:40 eben bemasc: that might be possible, sure.
13:40 homunq bemasc+
13:41 eben maybe adding kind:book would work.
13:41 That menu could look for things with the "kind" metadata key set.
13:41 bemasc eben: I'm thinking just maintaining a few high-level categories of mime types.
13:41 eben bemasc: Well, it does that already...
13:42 bemasc so I can say "What: Images" and see everything that's a jpg or png or svg or ...
13:42 eben We have: image, movie, sound, text, data I thikn
13:42 bemasc: That's already there, for images!
13:42 bemasc I thought we might.  So what:text is not good enough?
13:42 eben bemasc: Well, not if the categories cross mime-type boundaries...
13:43 what:text gets close, but it's certainly not true that all texts are books, or vice-versa.
13:43 bemasc I don't think "book" is a useful designator.
13:44 homunq what: book, which is just a subset of what: text with no new programming?
13:44 bemasc but "book in the third grade curriculum" is.
13:44 eben bemasc: arguable, but I might agree.  But I'm just thinking of ways to delineate more clearly.
13:45 homunq: well, maybe if you define a mimetype for that it could be....
13:45 homunq: But right now, no....there is no what:book right now.
13:45 bemasc eben: objects can only have one mimetype, though, right?
13:45 eben bemasc: right
13:45 bemasc The obvious solution is to make the library a webpage on the server where kids can download a book.
13:45 homunq but just a list of mime types - pdf, whatever native ebook format we choose.... the static ones.
13:46 bemasc With unmadindu's work, the book pops up on screen immediately, and also gets saved to the journal for future reference.
13:46 eben I'm basically saying that right now, the what: filter is based on mimetype, and the "smart" part groups various related formats together by high level category.
13:46 That's all we have right now.
13:46 bemasc homunq: the problem is that ODF is maybe sometimes a "book" but not always.
13:46 eben homunq: yes, that would work, if the book formats chosen are unique....
13:46 bemasc The problem is that we want tags like "this book is for 7th grade history" to come along with the download.
13:47 eben unique to books, that is
13:47 homunq metadata with download.
13:47 eben bemasc: metadata with download is trivial.
13:47 homunq that is a good concrete problem
13:47 eben we can add any amount of metadata we want.  Then there's the issue of exposing it.  I have a design for that.
13:47 Need to publish it.
13:48 homunq one solution: webpage magic to give you either a pdf or a pdf-with-metadata-bundle
13:48 depending on whether you are an XO or not.
13:48 bemasc chr__ proposed a mechanism for this, by creating an activity that is Browse but limited to a single website, and adds the keyword "book" to any download.
13:48 eben I don't think "just a webpage" satisfies me.  But I think saying that the library is an activity which can read content repos from various places and display them nicely is a good way to go.
13:49 I could imagine being able to add additional URLs for new content repos which support the protocol...
13:49 As I understand it, this is just the kind of thing that OLE was working toward, right?
13:49 homunq eben: metadata with download is trivial? link or handwaving, please?
13:50 chr__ eben: Yes
13:50 homunq also, consider security: I want foreign metadata to be limited in some way.
13:50 eben homunq: An activity can set any metadata it wants on Journal objects!  (Of course, until just now, it wasn't stored across reboots)
13:50 chr__ we are working on this, but do not have the local content browser
13:50 bemasc eben: the problem is to figure out what metadata to use!
13:50 eben So the Library can initiate the download, then apply any metadata it deems necessary based on the feed from the content repo.
13:50 bemasc: That's a separate problem than the one homunq just brought up.
13:51 homunq eben: but how do you code the metadata in html and have browse (or Bookbrowse) set it.
13:51 ?
13:51 bemasc one obvious proposal is to modify Browse so that the contents of any "rel=" element in a hyperlink are saved as keywords on the downloaded object.
13:51 chr__ I am hoping that we can get this working well on the XO and then port it over to a cross platform solution
13:51 eben And it also depends on how you want to show it.  I agree that making the Journal smarter about categorizing would help.
13:52 homunq bemasc+, though I still say you need to filter for security
13:52 eben homunq: That's what OLE has been working on.
13:52 bemasc <a href="book1.pdf" rel="3rdgrade science nepal book">Science Textbook</a>
13:52 eben They have formats for storing all the data.
13:52 It's just a little extra work in the activity to get that info from the server and set it on the object.
13:52 I don't understand why you're both so insistent that this be literally encoded into HTML.
13:53 _bernie chr__: making activities work on other platforms was a goal of 0.84, iirc.
13:53 bemasc eben: so that Browse can download files and get the metadata for them automatically.
13:53 eben XML of any kind is fine.  RSS would be an example solution.  Etc.
13:53 bemasc: Why Browse?
13:53 Why not Library?
13:53 _bernie chr__: not sure we have the manpower to do it now, but maybe OLE could sponsor this development for their own needs.
13:53 bemasc eben: because it's less work by orders of magnitude, and highly effective.
13:53 chr__ It seems like we have decided that the Library and the Reader are separate activities. If so, is anyone working on making the current Read activity nice to use?
13:54 homunq eben: rss is good, but html is the king of cross-platform
13:54 eben chr__: A few people have interest in doing so, I believe.
13:54 _bernie chr__: I think we're missing manpower to do this too
13:54 eben We all know that it's not great, and we all know that it really needs to be.
13:54 bemasc eben: if the Library is a webpage, then it can be nicely integrated with moodle,for example.
13:55 eben bemasc: I was under the impression that OLE was intending to create a client for use with their system.
13:55 bemasc eben: It was not clear to me that they were already set on writing a new client-side executable for accessing server-side content.
13:55 eben Anyway....sure...we could create some additional URL formats, too, if you wanted...
13:56 to make Browse do smart things with metadata on download.
13:56 homunq for security: <a href="book1.pdf" rel="3rdgrade science nepal book">Science Textbook</a> becomes www.mylibrary.org:3rdgrade etc.
13:56 _bernie eben: OLE Nepal, otoh, wrote a web frontend to fedora (as opposed to a SOAP/XMLRPC/REST based one) which would work fine with Browse
13:56 eben bemasc: I inferred this from their presentation at SugarCamp; I might be wrong, and I don't know if resources are there for it.
13:56 chr__ eben: at this point we have a web based library interface that if functioning but not so nice to use. We are hoping to provide offline access to content in the future.
13:56 _bernie eben: multiple interfaces to the library were also a design goal of OLE Boston.
13:56 bemasc right.  Local access to offline content.
13:56 _bernie as far as I understood
13:56 homunq ie foreign tags are tagged as such. I don't want a website to spam my personal tags.
13:57 bemasc homunq: I don't think you should worry about it.  You trust them for the data, so you trust them for the metadata.  If our metadata storage is way inefficient, we might need DoS protection, but that's about it.
13:57 eben homunq: we could limit to metadata, rather than plain tags, too.
13:58 homunq eben+, that is a good compromise
13:58 bemasc What I am saying is: with this slight change to Browse and the webpages, the Journal would be a pretty good browser for ebooks.
13:58 homunq it would obviously be very attractive for spammers if sugar were bigger, otherwise.
13:59 bemasc homunq: you are not making sense to me at all.  There is no security problem here.
13:59 chr__ As a way to test some of what we are talking about, what would it take to create a Library activity that is just another browser that downloads to "Book Shelf" activity that is based on the journal?
14:00 eben chr__: I don't think you want to do both.
14:00 chr__: If you make a new activity, I think it should be Library/BookShelf (though it could embed a web view)
14:00 homunq I go to website x. They put metadata on everything I download from there that makes it show up in all my favorite tags, just to spam me.
14:00 That is nonoptimal.
14:00 bemasc homunq: so you delete the thing you downloaded.  The end.
14:01 chr__ At this point OLE is not interested in creating an ebook reader that is specific to the XO.
14:01 bemasc at least if you use tags, the user can easily clear them in the detail view.
14:02 eben chr__: but you are interested in the Library part?
14:02 chr__ eben:  right
14:02 eben chr__: OK, cool.
14:03 So yes, I would say focus on a nice way to browse a library of online/offline content....it could be a web view based on Browse with a specialized toolbar...
14:03 homunq OK. But at least add another metadata tag of source url, so I can mass-delete all the spam when I realize it.
14:03 chr__ eben: if it is true that Sugar activities can run on any computer than an ebook reader might be possible, but at this point our funding is limited.
14:03 eben Or it might be a GTK app which reads data from the server via some other protocol.
14:03 whatever works.
14:03 homunq: that's something we should be doing anyway...
14:04 homunq: open a ticket for Browse on that?
14:04 homunq OK.
14:05 chr__ One agenda I had for this meeting was to find out what it was that Nepal was missing, and it seems to me that it was the Reader. They are fine with their current library and downloading to the Journal.
14:05 bemasc I don't think any of this is necessary.  Instead, I think we should focus on devising a system so that OLE can focus on producing a webpage listing of books.  When Browse downloads a Book, it should be stored in the Journal in a way that makes it as easy as possible to retrieve and contextualize.
14:05 chr__ Is it possible to shift the focus of this meeting to that, the Reader issue?
14:06 bemasc chr__: certainly.  I think we all agree that a lot of work is needed to improve/replace Read.
14:07 chr__ bemasc: is it possible that there is an existing project that could be ported?
14:07 bemasc chr__: I was just looking around for one.
14:08 _bernie bemasc, chr__: I think at this point manugupta would like to introduce himself and tell us what resources would be available to do this work
14:08 chr__ _bernie: great
14:09 it is getting late for them too.
14:09 _bernie bemasc: would the current pustakalaya work for us? or is it too rigid?
14:09 ok I'll ask this another time
14:09 manu, GA
14:10 bemasc _bernie: I don't know what it is.  It's flash, though, right?  I don't have flash.
14:10 _bernie #topic Resource availability and coordination (manu? arjun?)
14:10 bemasc: no, it's bare html: http://www.pustakalaya.org/
14:11 chr__ _bernie: are you talking about the library or the reader?
14:11 _bernie bemasc: I mean the library, not the online book reader...
14:11 chr__ _bernie: I think he was talking about finding a book reader
14:11 manugupta Hi, great conversation here. I work as a manager in operations research and product design division for a consulting and product development company.  We came with a framework before the meeting, and I think we need more exploration on how we want to proceed.
14:12 bemasc Yeah.  Unfortunately, good ebook reader software is very specific to the hardware, and the XO is not very much like any other existing ebook reader.
14:14 manugupta _bernie: I'll keep this meeting on evolving the ideas. Allocating resources, time and people can be figured out once we have a basic requirement set-up in mind.
14:14 bemasc my feeling is that such an agreement on basic requirements is impossible.
14:15 This is the sort of detail issue that cannot be decided by a committee.
14:15 (especially a committee without any structure)
14:15 chr__ If we focus on the Reader activity, are there requirements, bugs, features that have already been collected?
14:16 bemasc http://wiki.laptop.org/go/Book_reader_feature_set
14:17 http://wiki.laptop.org/go/Disc[…]eature_set/Actual
14:17 all of this is the usual wiki stuff: long lists of contradictory requirements written by many people, often with arguments inline.
14:18 chr__ Is there someone who knows the biggest problems, complaints, missing features we need to address?
14:19 Who has done the most work on the current reader?
14:19 bemasc unmadindu?
14:20 manugupta chr__:  marcopg, tomeu and morgan.
14:20 unmadindu morgs maintains it - I do weekend hacks on it ;-)
14:20 morgs :)
14:21 tomeu I used to work about two years ago ;)
14:21 was my introduction to sugar
14:22 chr__ Is there someone who is willing to make a list of things that the reader needs to do in order to make it work well?
14:22 morgs The current Read activity (a) doesn't support all the formats people want, (b) requires you to get the content into the journal before opening it, (c) has unreliable collaboration/file sharing and (d) has crashes in evince
14:22 homunq is there any open source tool that allows highlighting and post-its on any static format?
14:22 bemasc (e) is slow
14:23 (f) is very difficult to use on an XO in ebook mode
14:23 unmadindu (g) zoom can cause OOM
14:23 morgs (h) depends on evince patches not yet upstream
14:23 tomeu d == g?
14:23 homunq (i) has no ability to highlight or make margin notes
14:23 tomeu I think upstream evince has i already
14:24 bemasc evince has highlight.  I don't know about annotation...
14:25 homunq bemasc: persistent highlight?
14:25 unmadindu no annotation yet
14:25 there is some code lying around from GSOC work
14:27 chr__ manugupta: Is any of this work that you are interested/capabile in taking on? Or finding/building a new solution?
14:28 Would any of these problems be solved chose an ebook file format to get working well instead of pdf?
14:28 manugupta chr__: sure.
14:28 chr__: pdf is good.
14:29 bemasc Some PDF files are good for some things.
14:30 Many PDF files require enormous amount of memory and CPU to render overly detailed vector images, making them unsuitable for use on XO.
14:30 unmadindu eg: maps
14:30 bemasc Others cram a huge amount of text onto one page, making navigation difficult on a small screen.
14:31 Some even have pages in different sizes, requiring different approaches to navigation for each page.
14:31 Or have huge empty (or almost-empty!) margins that waste screen space in any naive layout algorithm.
14:32 chr__ what about something like https://addons.mozilla.org/en-[…]irefox/addon/5275
14:32 OpenBerg Lector
14:34 bemasc last updated over a year ago, doesn't work in FF3, doesn't read pdf...
14:34 _bernie (sorry, I've been on the phone for a while)
14:34 bemasc http://en.wikipedia.org/wiki/C[…]of_e-book_formats
14:34 morgs PDF has the advantages that (a) there is a lot of content out there already (including files we can't read, as bemasc mentioned) and (b) people know how to produce PDFs using various tools.
14:35 I think we shouldn't try to interoperate with bad PDF files, but rather as a complementary project, help people to produce good PDF files...
14:35 chr__ I agree that we need to support PDFs, I just want to make sure that PDF support is not holding us back from creating a great user experience.
14:36 unmadindu there are a few tools which create Sony Reader optimized files from a number of file formats, maybe we can look into that approach ?
14:36 chr__ It seems like there is more and more ebook content and it would make sense to support that if it is easier to do, and then worry about PDF later it that is causing a headache.
14:37 morgs http://wiki.laptop.org/go/Read_Etexts is a derivative which supports the Gutenberg Etext format instead of PDF. I'm considering merging it into Read...
14:38 unmadindu plans on trying to make a text backend for evince
14:38 chr__ Does the Reader activity support any ebook formats now? Does it work the way we want it to with some file formats and not others?
14:39 bemasc unmadindu: umm, Gutenberg Etexts are just .txt, right? So coordinate with morgs...
14:39 unmadindu ok
14:39 and I think we should enable support for djvu in the builds
14:39 bemasc chr__: I think only PDF is supported in Read.  There was some mention of DjVU, which is basically just an image of each page.
14:40 _bernie "Outside of a dog, a book is man's best friend.  Inside of a dog it's too dark to read." -- Groucho Marx
14:40 lol
14:41 morgs Groucho Marx didn't have a backlit 200dpi screen :)
14:41 _bernie morgs: is Read MVC?  I mean, does Read make it easy to integrate multiple formats?
14:41 morgs _bernie: Read is a wrapper around evince...
14:41 it tells evince to load the document
14:42 _bernie morgs: or does it make more sense to have separate activities for each book format, maybe with a toolkit to share common UI code?
14:42 morgs and one journal to rule them all?
14:42 _bernie morgs: clearly, Browse is already the "HTML book" reader.
14:43 morgs: so if Read is the PDF (and related formats) reader, other formats might come in separate apps.
14:43 morgs I think our activity strategy was originally to do one thing and do it well, unixy...
14:43 _bernie morgs: exactly, the journal knows which one to start
14:44 morgs Unfortunately Read got the good name :)
14:44 _bernie but a common UI and functionality (for bookmarks, annotations, etc.) would be really useful.
14:44 morgs yes
14:44 and key bindings etc
14:45 bemasc It might make sense to have one viewer for page-by-page formats (pdf, djvu, ps, dvi) and one for flowed documents (html, docbook, txt)
14:46 chr__ It seams strange to me that Activity names are not connected to the action they are named after. If i want to read a file, and it happens to be html, I would think it strange that it opens in the browser.
14:46 morgs Oh, another issue: (j) Hyperlinks in PDFs can't be easily opened in Browse
14:46 _bernie morgs: the good name? it depends on how cool you think "Read" is in kids' minds.  Probably Superfun and Megablast would get more clicks than Read :-)
14:46 morgs hehe
14:47 _bernie chr__: yeah, this is because the Activity concept is just a... concept.  the reality of computers is that each format needs a *program* to handle it.
14:48 document centric systems (like the old MacOS) actually annoy users when there are multiple applications for the same format and the system insists on running the wrong one.
14:49 bemasc _bernie: that's why we let the user choose.
14:49 _bernie and on windows you see applications removing each other from the file associations in an attempt to prevail :-)
14:50 tomeu _bernie: you mean 20th century computers, like?
14:50 s/like/right
14:50 _bernie bemasc: we do?
14:50 oh yes, we do.
14:52 bemasc OK, I think people have a good sense for what the problems are.
14:53 goes to get lunch
14:55 homunq thinks that, given that we made it to j, a well-done single-format ebook reader from another project might give Read a run for its money for what OLE wants
14:55 given that redoing to format X is doable for them.
15:01 chr__ Thank you all for you input, I have to run now.
15:01 manugupta Thanks to all for joining us today.
15:02 chr__ If anyone has any ideas on how OLE could help get the Reader working well let me know. chris at ole dot org
15:29 homunq hmmm... after looking at openberg, I think rebuilding something similar is the way to go. The format is just bundles of page-separated html / xml. The renderer is just the browser engine (gecko for us). The reader adds the interface.
15:31 The reader could do some magic page-flipping, too.
15:33 there is definitely work involved, but building this from parts is not much more work than normal sugarizing.
15:33 chr__: does that interest you?
15:38 much of the work involved is useful for sugar in and of itself. For instance, since the format is a bundle of web pages, getting this integrated is useful for offline browsing.
16:07 chr__ it seems like Okular http://en.wikipedia.org/wiki/Okular would be a good reader to work from as well
16:08 bemasc I just sent a message to the folks at mobileread.com
16:08 which seems to be a forum for discussing all things ebooky
16:09 also http://www.sonystyle.com/wcsst[…]der_createPDF.pdf
16:10 which is sony's document entitled "Creating PDF's for the Sony Reader"
16:10 we might benefit from something similar
16:12 intriguingly it will also reflow pdf-based ebooks
16:13 but of course this only works if they're basically only text.
10:03 walter good morning
10:03 tomeu hi all
10:04 goes check which meeting is now
10:04 walter this is the OB meeting, I think.
10:05 tomeu hmm, the calendar widget in my gmail account seems to be broken
10:06 walter actually, I have a SL community meeting in my calendar... slobs next week.
10:06 who runs the community meetings?
10:06 tomeu ok, community meeting sounds good as well
10:06 walter: what team is that?
10:07 walter too many teams, obviously
10:07 I am not sure what community is except the aggregate of all we do?
10:08 tomeu yup
10:08 walter well, maybe we can talk about some pressing matters while we wait for the community to join us.
10:08 tomeu though we don't have a general meeting
10:09 walter What I am struggling with is what to ask of a group that is interested in porting Sugar to both a new piece of hardware and a new distribution on a large scale.
10:10 We of course want to help in every way we can, but what should we ask of such a group in terms of resources to guarantee success?
10:10 tomeu hmm
10:10 walter A team to work with the distro maintainers
10:10 A testing team
10:11 A team to work out any specific h'ware related issues?
10:11 tomeu perhaps we could create a space to perform that project? a section in the wiki, a set of git trees, shell accounts to their members, etc?
10:11 just to have something tangible to show
10:11 walter and as they are doign this because of their interest in deployments, presumably an education team
10:11 good idea. de we have an infrastructure meeting in an hour?
10:12 tomeu something like a porting process?
10:12 hmm, process is not the word...
10:12 walter yes.
10:12 a guide to porting sugar and a guide to deploying sugar
10:12 tomeu oh, a porting programme
10:13 walter we should perhaps have a team that helps this process along--but it could be the deployment team's main task
10:13 tomeu hmm, yes
10:14 as real deployments would be conducted by local deployment teams
10:14 the global deployment team would be tasked to support the local depl teams and to extend sugar to new hw platforms and vendors
10:15 walter well, I think the extending to new platforms may be undertaken by regional teams as well...
10:15 working with a regional distro, for example
10:16 tomeu one of the important points of a porting programme is that we can tell a prospective org: send us an email with the names and email addresses of the initial integrants of the team, and we'll set up infrastructure for you, create communication channels with people that will help you, etc
10:16 yes, regional distros are very important
10:16 walter good point. but how do we help them assemble the right team?
10:16 tomeu so perhaps it shouldn't be so much coupled to the deployment team
10:17 walter we should have a set of guidelines as to the sorts of talent they will need.
10:17 tomeu sure, though that could be a second step?
10:17 the initial integrators of the team don't need to be technical people
10:17 walter yeah. iterative design :)
10:18 tomeu just the people form the organization that are pushing for doing sugar stuff
10:18 yeah, I'm interested now in unblocking the process
10:18 and give visibility to the process
10:19 walter Sounds straight forward enough.
10:19 tomeu once there's fluid communication between all stakeholders, we can propose first steps such as choose one distro that already run on the hw, choose a similar distro that already has packages, install those and do some testing, identify problems and communicate them through trac, find resources to keep working, etc
10:19 walter I will try to write up a simple set of guidelines this weekend then...
10:20 BTW, thanks for the translation. I'll be rebuilding TA today sometime and I think Sayamindu is about ready in the Pootle front as well.
10:20 tomeu walter: you have already been in contact with such people from other organizations that have shown interest in sugar, like the caixa magica people
10:20 what could have we done so that their involvement would be more visible and they would feel compelled to discuss how to work forward?
10:21 welcome, wasn't too hard
10:21 walter Mandriva, for example.
10:21 tomeu if it's a hw company, we could designate someone form the oversight board to conduct private conversations, for example
10:22 or a linux company that needs for any reason to have some secrecy at first, yeah
10:22 walter It seems that the distro will be between Sugar and any hardware, so it is more the matter of dealing with the distro, I am guessing.
10:23 tomeu true from the technical point of view
10:24 but who should be interested in being able to offer sugar would be a marketing department, right?
10:24 and normally distro companies don't sell hardware
10:24 walter I don't know if there is a one-size fits all answer
10:25 tomeu yeah, I guess we can find many cases
10:25 governments are also interested in having a say on what software runs on the machines they buy
10:25 walter absolutely.
10:31 tomeu nice, one more portuguese interested in localizing
10:31 (in localization@lists.laptop.org)
10:31 walter yeah. just saw that
10:33 tomeu hmm, we could have a category in the wiki Platforms and another Distributions
10:33 then one page for each hw platform sugar runs on
10:33 and form there point to the distros that work on that platform
10:33 and have some status, comments, todo list, etc
10:33 walter yeah. the supported system page is a mess right now
10:34 tomeu supported systems is supposed to be exhaustive or just a way for people to get sugar easily?
10:35 walter I think we need a top-level get sugar page and more detailed matrix for supported systems as you describe.
10:35 right now we have neither... just a hard to follow mess
10:43 tomeu yup, we should give good thought in the next meeting to ways of best welcome people interested in porting sugar to other hw or sw platforms
13:34 _bernie #endmeeting
10:42 eben #topic overlay chat
10:43 Did everyone find the PDF for today's meeting with the agenda?
10:43 Here's the link: http://sugarlabs.org/wiki/imag[…]y_chat_sketch.pdf
10:43 tomeu quite nice
10:44 aa haha
10:44 bertf takes too much space
10:44 tomeu how can you hide the bubbles?
10:44 and what if the buddies toolbar is overflowed, thus has scrolling arrows?
10:44 eben OK, so I can give a very brief overview of the ideas here.  It's certainly just a quick sketch; we haven't had time to go in depth here yet.
10:45 tomeu ok
10:45 bertf no time? this has been in designs for 2 years I think
10:45 i've certainly seen it before
10:45 eben So, as Tomeu noticed, the bubbles correspond to the XOs in the Frame.
10:46 aa will this become the famous bulletin board?
10:46 eben bertf: Sure, but the topic was added to the agenda (and became a short term goal) just last week, and since then I've had no time to update or investigate further. :)
10:46 bertf eben: hehe. what would we do without pressure, he? ;)
10:46 aa: that's different
10:47 eben We thought that the right edge of the Frame, as the presence indicator, would do well to be used to more potential.
10:47 bertf (me thinks)
10:48 eben The thought is that this extra layer of infothe chatcould be toggled on and off via keyboard (there is a key for it on the XO).
10:48 As you see in the first couple of slides, the message is truncated to a fixed width when it appears, so as not to cover the whole screen.
10:48 tomeu and for non-xos, have a shortcut discoverable by looking at the activity palette?
10:48 eben tomeu: indeed.
10:48 We should add overlay chat, view source, etc. to the activity menus...
10:49 tomeu sounds good
10:49 aa eben: where is the input widget?
10:49 eben Then, in slide 3, you can see that the message expands on rollover to reveal itself.
10:50 cms the input widget could be in the palette of an XO in the frame
10:50 possibly?
10:50 eben Input is an interesting question
10:50 cms perhaps when hovering over your XO
10:50 eben One option is that there is a way to invoke it, and it appears as a bubble next to your own XO...
10:51 that is, the input box is just like a message bubble, but editable.
10:51 bertf I'd prefer a fixed-width window with wrapping that can be resized and dragged around. preferably with adjustable translucency.
10:51 cms i like that idea
10:51 bertf: i think it should work within the given paradigm
10:51 eben bertf: I assume that's 3 jokes in one sentence?
10:52 bertf eben: no. fixed location is bad. non-wrapping does not work anyway. translucency is debatable
10:52 cms actually, i think fixed location will be better. more discoverable
10:52 and relating it to one's XO makes sense
10:52 bertf eben:  the "window" might be a misnomer though
10:53 cms we are trying to link the chat bubbles to the XOs directly, so that this can become a device to use in neighborhood and groups as well
10:53 eben I don't think that a draggable window is useful.  On small screens in particular, you'll just be dragging it around every couple of seconds.
10:53 bertf cms it might cover an essiantial part of the Activity UI
10:53 aa bertf: that was more along the lines of my idea (re: "I'd prefer a fixed-width window with wrapping that can be resized and dragged around. preferably with adjustable translucency.")
10:53 eben The intent of the overlay is to be able to toggle it on/off as desired, instead of needing to drag windows around (which we've avoided thus far in the UI entirely)
10:53 aa bertf: well, almost exactly my idea...
10:54 my intention was to do a modular overlay with extensible widgets
10:54 one of them could be a chat widget
10:55 bertf eben: overlapping windows were invented precisely for limited screen real estate. they just wennt overboard with it, putting whole apps into windows, which does not make sense
10:55 aa also, from a performance POV, using a prerendered window with compositing will improve the experience
10:55 bertf I could see a slide-in/out interface, where just the last message is contiuously visible
10:56 eben bertf: I don't understand why a draggable window is better than a toggle.  Could you weigh some pros/cons?
10:56 bertf eben: I'm imagining a collaborative session
10:56 eben: where someone is typingh (a mentor perhaps)
10:56 and the other is mousing around
10:57 but e.g. in etoys the object viewer is on the right edge
10:57 it would be covered by the chat lines
10:57 cms we had an earlier concept with floating bubbles
10:57 bertf so I'd move it to the left edge
10:57 cms but i think this one is much stronger
10:57 and creates a link to the other zoom-levels
10:58 eben Hmmm, well our toolbar design purposefully puts all major controls along the top edge.  I can see the argument, though.
10:58 cms perhaps we should illustrate first how this same mechanism can apply in the other zoom-levels
10:58 and then come back to this discussion?
10:58 eben Clearly translucency could be useful, but I doubt we can do it.
10:59 bertf let the e3ngineers worry about that ;)
10:59 tomeu heh, every time designers say that, crap happens :p
11:00 bertf tomeu: he's just saying hoping someone proves him wrong
11:00 eben: anyway, translucency is optional
11:00 tomeu I would prove him wrong, though cannot find my X tools
11:00 bertf but I do think you need line wrapping
11:01 eben OK, so let's briefly address the topic Christian mentioned.
11:01 We really visualize this as part of a larger idea, which is the introduction of chat throughout the zoom levels.
11:01 bertf nice idea
11:01 eben In Home, for instance, you might be able to set your personal away message.
11:02 In Groups/Neighborhood, we'd like XOs to be able to have transient chats.
11:02 cms i think adding live chat to groups and neighborhood should be top priority
11:02 it will bring these views to life in a way we haven't seen yet
11:02 eben Naturally, as the XOs are represented in these views, we'd like to associate the bubbles with the XO icons on screen.
11:02 bertf cms activity chat should be toppest priority though
11:03 eben Also, it seems natural to us that these chats are, as I mentioned, transient.  You see what you're around for, and you miss what you're not....as if you were or were not in the room when something was said.
11:03 I find this to be a good way to think about it, and it doesn't result in the question of whether or not chat transcripts are permanent, or stored, etc.
11:03 bertf too much real-world metaphor here
11:04 cms bertf: i don't think there can be too much real-world metaphor! ;)
11:04 aa I could clearly see how a general chat in the neighborhood view could get really crowded really quickly....
11:04 eben And I really like the idea that the buddies in the Frame are the virtual representation of activity participants, and the logical place to associate chat bubbles with in the activity view.
11:04 bertf i disagree
11:04 (w cms)
11:04 cms body-related and real-world metaphors form the basis of the entire UI design
11:04 that's our premise
11:04 eben aa: Perhaps, but there are good examples quite similar to ours which work well.
11:04 cms moving forward, that is one of the core principles we need to continue to uphold
11:05 eben And since these messages are fleeting, the screen won't fill up so much.
11:05 bertf eben: perhaps I misunderstood the whole design then
11:05 eben And, finally, it is an additional layer of the UI; it's not permanent.
11:05 cms bertf: please see my sugarcamp presentation
11:05 it explains the UI rationale
11:05 bertf eben: are you saying those bubbles are not ordered chronologically?
11:06 eben bertf: No, they are associated with the XO icon in the Frame.
11:06 bertf eben: I see. wellm that's different
11:06 eben As seen in the last slide.
11:06 bertf cms: link?
11:07 eben They appear adjacent to the corresponding XO.  There's still the question of what to do if the activity list overflows...
11:07 cms http://sugarlabs.org/go/Market[…]eam/Presentations
11:07 bertf eben: that's totally non-obviuos from the last slide
11:07 cms "Design Opportunities for Sugar"
11:07 aa eben: so new messages from the same buddy would overwrite old ones?
11:07 eben bertf: Agreed; as I said, no time!  I threw together this PDF in the 10 minutes before the meeting.
11:08 bertf eben: the bubble needs to be on top of the frame and extend behimnd the xo guys, also, the xo guy should be visible in the bubble then
11:08 eben aa: Yes.  Although they would proably be queued on the display end.
11:08 bertf: Yeah.  I think you're right, there.
11:08 aa how would that work in th eneighborhood?
11:08 bertf aa: little bubbles next to the xo guys
11:09 yes, I can see how that may be nice
11:09 eben bertf: little bubbles, likely centered above the XOs.
11:09 bertf eben: I'd extend them behind the xo guys, like I propsed for the frame
11:09 aa you loose chronological ordering there
11:10 eben I understand the wrap comment; my thought was that if the input bubble matched the actual speech bubble, we could naturally limit to screen width.
11:10 bertf aa: there is no chron order in the activity either
11:10 aa bertf: exactly
11:11 bertf it's unusual but not necessarily bad. can someone whip up a demo?
11:12 eben That's correct, the chat is transient, and only chronological inasmuch as they appear in sequential order
11:12 bertf it has a bit of twitterish feel, this is even worse than IM
11:12 whichh at least has a back log
11:13 aa I agree
11:13 eben Well, that was a conscious decision, I think.
11:14 bertf it's been decided already?
11:14 cms it will enliven the zoom-level views, and the interaction within activities
11:14 bertf why are we here then?
11:14 eben Our impression was that there would also be an embeddable chat widget for activities to use, and that activities which depended on persistent chat/backlog would do better to add that as part of the UI itself.
11:14 No, it wasn't decided.
11:14 bertf then don't say that ;)
11:14 eben It was simply our operating assumption in this first round of sketches.
11:14 aa I'm not saying the idea isn't interesting, but I don't know if this is the most efficient and efective way of delivering what users are asking for
11:15 bertf aa: what are users asking for?
11:15 eben It was a conscious decision in the making of the PDF we're discussing.
11:15 bertf ok
11:15 aa no one has complained about the chat activity, except for the lack of notifications
11:16 bertf: what I've heard repeatedly is a way to comunicate while sharing an activity
11:16 eben aa: That's true.  However I also question if duplicating the exact functionality of the Chat activity is useful, too.
11:16 Maybe it is. ;)
11:16 cms i think the purpose of in-line chat is different from the purpose of the chat activitiy
11:17 eben But we were exploring other methods to add a communication layer that weren't as strict, and which could work naturally in the other zoom levels as well
11:17 cms what we are attempting here is more transient
11:17 bertf so this is basically a speech bubble next to each XO guy with the utterance he did last in the active zoom level
11:17 cms it's a more informal way of chatting
11:17 aa eben: I agree, that's why my proposal is to build an extensible overlay, which would have a chat as one of its many potential features
11:17 maybe following the ideas behind the control panel
11:17 (implementation-wise)
11:17 eben aa: That kind of sounds like a monster to me.
11:18 bertf did I sum this up correctly?
11:18 bemasc aa: to work well, chat needs to be immediately visible.  Push, not pull.
11:18 cms aa: chat was always a part of the zoom-levels from the get-go, just didn't make it into implementation yet. i think it's important that it lives within the views directly, not as a separate overlay, because it will serve to enhance the functionality of these views
11:18 eben Before you know it, we'll have 12 should-be-activities implemented in the overlay and the difference between activities and overlay will be confused.
11:19 bertf: Yes, that's correct.  It's a "you should draw some clouds!" or "nicely done!" or "click on the button that looks like a duck" type of system.
11:19 bemasc I think we should push as much functionality as possible into the overlay.  Anything that is generally useful regardless of the underlying activity should be there, so that activity authors only ever have to implement what's new about their activity.
11:19 eben Not a historical record of a conversation.
11:20 aa cms: I dont see why this would need to ignore the current zoom level
11:20 in fact, I agree it would be completely dependant on it
11:20 eben aa: His comment is one of visual presentation
11:20 bertf aa who said it should ignore zoom?
11:20 bemasc I think eben's mockup is a great place to start.  If we decide we really need a more chat-like view, we can also add that, available from the right-side frame.
11:20 cms aa: i think it's more a matter of approach. by integrating chat directly, we bring out the full potential of the zoom-levels, by which i mean, this is what we initially designed them to be able to do!
11:20 aa bemasc: it would be completely visible, this would be a window that show()s when abutton is pressed
11:21 eben A big rectangle with some tabs and a chat widget inside it is completely separated from the view.
11:21 We'd like to integrate the chat with the view, and correlate the discussion with the representations of the people who are communicating.
11:22 aa ok
11:23 eben Sure, I suppose that there could potentially be some sort of "detach" button, which pulled the conversation out into a separate window, covering the activity (a la the settings window)...
11:23 bemasc the overlay chat looks, to me, almost exactly like twitter (but with separate contexts).  I'm not a twitter user, but many people are, and it seems to be worthwhile for them.  This approach certainly extends naturally to the Neighborhood view.
11:23 bertf I think the bubble should slide out as soon as the text was received, and slide back after a few seconds. Mouse-over would slide it out again
11:23 eben that could even keep backlog, perhaps
11:23 cms eben: that seems like a good idea
11:23 bemasc eben: sounds good to me.  Either way, how do I type a message?
11:23 eben bertf: yeah, that's kinda what we're aiming for!
11:23 bertf eben: well you did not say that yet
11:24 eben The slide would be great to have, and it will match the notification system in that regard.
11:24 My fault. ;)  That's the ideal implementation in my mind.
11:24 And it further emphasizes the relationship to the people in the Frame.
11:25 bemasc wishes for compositing...
11:25 aa bemasc: I think twitter is an effective micro blogging mechanism, but not a very useful IM tool
11:25 bertf as for history, there could be a separate tab in the journal for all received bubbles, ordered by time, filterable ...
11:26 or maybe not
11:26 bemasc bertf: my instinct would be to not record the contents of the overlay in the Journal.  It's deliberately ephemeral.
11:26 eben aa: I think many non-IRC folks use IM much like this system will function actually.  Usually messages are rather short, and scrollback is often ignored.
11:26 bemasc: I agree.
11:26 bertf bemasc: guess you are right
11:26 eben That was another reason we thought the transient presentation was wise, as one wouldn't expect the record to be permanent.
11:27 bertf eben: like sms before iphone ...
11:27 bemasc I think this system sounds great.  Actually, I wish Pidgin would do this, so I could see a small transient popup with each new message received, which would disappear after a few seconds.
11:27 eben But as I say, we might be best off offering a "detach" function with scrollback.
11:27 bertf: Heh, right.
11:27 aa eben: my take is that traditional-MSN/IRC-like IM is a proven IM tool, even with small kids, twitter is not
11:28 bemasc Then if I wanted to go review the context or type a message, it's just one click away.
11:28 aa eben: how IM is actually used is, at least, debatable
11:28 bertf eben: might have a 160 char limit too, and then we can hook up actual phones to that. like twitter
11:28 bemasc bertf: slow down!
11:28 bertf bemasc: thought we were brainstorming
11:29 eben we are. :)  We also need to sort out a loose roadmap for what parts of this can be done when.
11:29 Unfortunately, we're about out of time.
11:29 bemasc tomeu?
11:30 tomeu bemasc: yup
11:30 bemasc eben: do you have a mockup for how to send a message?
11:30 bertf eben: make a flash demo if you can. will illustrater mich better
11:30 eben aa: I know you were interested in this, in general.  What are your thoughts following the discussion so far?
11:30 bemasc tomeu: you were working on a popup chat widget, right?
11:30 tomeu bemasc: I could work on that as a simple fallback that gives something for 0.84
11:30 but haven't started yet
11:30 eben bemasc: No, not yet.  I can take a few action items on things to mock up, and we could discuss further next week, perhaps.
11:31 tomeu I'm ok with longer term discussions, but I would like to have something better on each release ;)
11:31 it should take less than a day to get it done
11:31 though would be much less fancy ;)
11:31 bemasc tomeu: I think our new design is just what you are describing, plus a popup notification for each new message as it arrives.
11:31 eben tomeu, aa:  If we think it's worth attempting, would it be possible to have something akin to the transient chat for 0.84?
11:32 bertf tomeu: actually the design discussed so far is really simple
11:32 bemasc The notification itself has some nice details from eben, but this is not a huge undertaking.
11:32 bertf tomeu: no need to even store a chat history etc
11:32 bemasc and we can start from either end (or both!)
11:32 aa eben: I dont know what the current workload for the dev team is, I cannot promise anything due to exams (fun!)
11:32 tomeu bemasc, bertf: oh, ok, wasn't giving enough attention
11:33 eben bemasc: It's not a "notification" in the strict sense....these bubbles don't really match the exact behavior of the generic notification system.
11:33 tomeu eben: what do you mean by transient? I thought all proposals were transient
11:33 eben But I agree, making a class for these shouldn't be too hard, given the notification stuff already built.
11:33 tomeu: Well, I mean in the little bubbles, adjacent the XOs, rather than just a widget in a window.
11:34 tomeu ok, the widget in a window is quite simple
11:34 we could target for that for 0.84
11:34 eben tomeu: right, that I know. :)
11:34 tomeu I can help aa if he needs
11:34 aa tomeu: I will :)
11:34 tomeu about the other space-age stuff, ...
11:34 bemasc ok, two people, working from both ends.  Fantastic.
11:35 tomeu not sure if it brings enough value to deviate energies in 0.84
11:35 bemasc I think overlay chat brings enormous value.  It makes our intention on collaboration crystal-clear, and is genuinely useful.
11:35 tomeu but there's no problem if someone wants to play and let it slip for 0.86 in case it's not ready at time
11:35 aa eben: I will need some mockups on the complete workflow (including text input and showing/hiding)
11:35 eben OK.  So let's wrap up.
11:36 My action items here are to create a more complete mockup, including:
11:36 tomeu bemasc: by that, you mean in general, or any of the concrete presentation models?
11:36 bemasc tomeu: in general.  I'm happy with any of these models.
11:36 tomeu oh, ok
11:36 eben 1. Chat in Neighborhood/Groups
11:36 tomeu I agree with that
11:36 eben 2. Use of away messages in Home
11:36 aa bemasc: absolutely, I've been asked for this in schools here
11:36 cjb aa: if we wanted to start with just an overlay box in the middle of the screen that has working chat, I think that would be 90% of the way there :)
11:36 eben 3. Transient chat in activity
11:36 tomeu aa: nice to hear that
11:36 eben 4. Text entry for chats
11:37 5. A "detached" version, with scrollback
11:37 aa cjb: I can probably hack that up by tomorrow :P
11:37 but I see the points on intergation with the views as valid
11:38 eben My key focus on the last point will be designing the detached (windowed) version in such a way that it will naturally relate to the transient chat bubbles....it won't look like the Chat activity.
11:38 bemasc eben: it's low priority, but I'm curious about the case of >10 participants, once they don't all fit on the frame.
11:38 cjb aa: yeah, I guess I'm thinking it's most of the technical work, but not most of the design work
11:38 aa >10 participants is unreal in the current state of connectiviy
11:38 eben bemasc: Yeah, I'm curious, too. ;)
11:39 bemasc eben: I think making it look like the chat activity but only taking a quarter of the screen, and attached to the right edge, would be fine.
11:39 We might as well make it clear that what is going on underneath is precisely the same as the chat activity.
11:39 eben I'd prefer to make the "bubbles" consistent with how we intend them to appear in all views, myself.
11:39 cms eben: yes, i agree
11:40 eben It shouldn't be too much work to style the bubbles, especially since they're just boxes in all mockups so far!
11:40 bemasc ok
11:40 aa maybe there could be some way of "detaching" the stack of messages on the right into a draggable chat-like window with scrollback?
11:40 eben I really think, if we're going to release this before we have the transient implementation, it needs to be as close as possible to the "detached" version of the "real thing"
11:40 tomeu eben: plan to do new mockups soon?
11:41 eben aa: I'm still against dragging, honestly.  I think it should take the form of a modal dialog (fill the screen, minus the edges)
11:41 tomeu: That's my goal for next week.  Can we have another descussion here next week?  (usually 1st and 3rd, but we can schedule them for 2nd and 4th as we need)
11:41 tomeu eben: that's so easy, that we could do that first, then see how well it works
11:41 eben: sounds good, this time is pretty good for me
11:42 eben OK.  So Let's plan on another meeting on this topic next week, same time, same place.
11:42 bertf eben: I'd punt on 5. for the time being
11:42 eben Christian and I will have some new, hopefully more convincing mockups to show, and well also work on the "detached" version as the short term solution.
11:43 bertf: Why punt?  It sounds like that's the one part that's feasible to do short term...
11:43 bertf imho detached is actually simpler to do
11:43 err no
11:43 the bubbles
11:43 pretty much stateless
11:44 bemasc bertf: if you had to do it from scratch, maybe, but we already have Chat.  This is just Chat-in-a-box.
11:44 tomeu detached==dialog and attached==bubbles, right?
11:44 eben bertf: Ah, but Tomeu has the stateful part mostly working, and it's simpler in terms of display (one window). But I won't argue if someone/anyone can make the bubbles work sooner!!!
11:44 tomeu right, what bemasc said
11:44 eben tomeu: correct
11:44 bertf well chat is doing fine,  why replicate it now?
11:45 tomeu bertf: it's tied to every activity
11:45 bertf *every* activity?
11:45 aa the bubbles would be inside the activity gtk.Window correct?
11:45 eben bertf: Heh, now you're on our side?  I thought you argued just the opposite before.  But let's not dwell on it now.  I'll work on mockups for the /whole/ system, and we can review next time.
11:45 bemasc aa: no, new windows.
11:45 bertf aa: no, in the frame
11:45 eben Thanks everyone!
11:46 bertf eben: I'm easily convinced ;)
11:46 eben (Feel free to continue discussion, but I'm going to close the meeting unless anyone has any final comments on the record)
11:46 cms thanks--talk soon
11:46 aa eben: thank you!
11:46 and all :)
11:46 bertf eben: I'm a fan of TSTCPW
11:46 someone lend me  a T
11:47 eben heh
11:47 lends a T to bertf
11:48 #endmeeting

Index | Today     Channels | Search | Join

Powered by ilbot/Modified.