Sugar meeting

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 localizationlists.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

#sugar-meeting, 2008-12-04