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 |