[chandler-dev] [Sum] IRC chat with folks from Sugar (OLPC)

On Monday, we had great meeting with the folks from Sugar. Here are  
notes and the transcript. (I may have munged up the technical  
discussions, so please jump in and correct!) - Mimi

*****
We began with general introductions. Grant, Jeffrey and I attended.  
Sheila and Jos eavesdropped;) I think there were 7 people from Sugar  
over the course of the meeting. (I may be missing some people who  
came and went.)

We each gave brief histories of our respective projects.

For those of you who are unfamiliar with Sugar, here is Ben  
Schwartz's brief summary:

The people who founded OLPC wanted to make a really cheap laptop,  
which meant it couldn't run any standard desktop, because it wouldn't  
have enough memory/CPU/disk.

They also wanted to provide an operating environment designed for  
learning, and specifically for their vision
of exploratory, freeform learning.

So they decided to write a new desktop, using GTK (because it is  
mature and support i18n well) and Python (because it allows students  
to explore and modify the code).

Sugar is the result of that.  eben is the lead UI designer, and tomeu  
and marcopg wrote most of the code.

There is also a team at Pentagram that has worked on visual/graphic  
design for the UI

*****
The lead-off question was: Can Sugar use Chandler's calendar?

Loading all of Chandler 1.0 onto Sugar is too much, but the calendar  
by itself for example is feasible.
- Porting pieces of Chandler would be an interesting approach. Sugar  
team is potentially interested in anything that might be relevant /  
doable, as they don't have very much in the way of task management or  
scheduling right now.

This led of course to a brief discussion about whether Sugar  
supported Wx.
-- The conclusion was unclear, but did not seem to be in the  
affirmative.

Sugar devs were particularly interested in the performance work we've  
done in the re-arch. Jeffrey pointed them to Phillip Eby's Trellis  
documentation. http://peak.telecommunity.com/DevCenter/Trellis

I briefly reviewed some of Chandler's core concepts: Integrated  
information management. Triage and focus management. Calendar is  
simply one view of your data, etc.

Which led to a discussion about Sugar's "Journal" and how it's  
similar to / different from Chandler's Triage List.

Also touched on the 2 projects sharing models.
- Sugar - Synchronous sharing, a lot of work on presence: Everything  
is designed to work in the absence of a server and/or reliable  
internet service
- Chandler - Asynchronous sharing, no work on presence

I went over our design process. In particular user interviews,  
testing and gathering user feedback through the list.

Sugar's development team faces some tough challenges when it comes to  
user testing. They have limited access to their users (1000s of miles  
away), who are also not likely to provide feedback by participating  
actively on a mailing list.

Jeffrey asked about linking to documents in Sugar?
Unfortunately, it is actively discouraged in Sugar for various  
reasons right now.

Which brought us to the issue of data storage. Chandler and Sugar's  
back ends are significantly different.
- Sugar: filesystem approach
- Chandler: email approach

NEXT ACTIONS
- Sugar: build Chandler (particular the rearch UI)
- Jeffrey put recent documentation up somewhere globally readable:  
http://people.osafoundation.org/~jeffrey/rearch_documentation/

Relevant Sugar documentation for Chandler-devs:
- http://wiki.laptop.org/go/Olpcfs
- http://wiki.laptop.org/go/Low-level_Activity_API#Datastore
- http://wiki.laptop.org/go/Journal_reloaded

Schedule another meeting? Talk more about storage?

*****
TRANSCRIPT
Oct 20 19:54:49 <bemasc>	JeffreyH: Hi, I'm Ben Schwartz
Oct 20 19:55:06 <JeffreyH>	hi bemasc, pleased to virtually meet you
Oct 20 19:55:13 <hamstar>	Hi Ben, this is Mimi
Oct 20 19:56:15 *	JeffreyH notes for bemasc that Chandler folks are
having a pre-meeting in #chandler, anyone's welcome to read back on
what we've been talking about,
http://wiki.laptop.org/go/Activities/All
Oct 20 19:56:29 <JeffreyH>	whoops, wrong link, I meant
http://chandlerproject.org/script/getIrcTranscript.cgi? 
channel=chandler&date=20081020&startTime=1016
Oct 20 19:56:59 -->	gbaillie
(n=gbaillie-h7H/nBbwi4OMI8HSDK2UVfcEJKo2Qz8o2YSdIXK86XYSWNiqpBikx6xOck334EZe@public.gmane.org) has joined
#sugar-meeting
Oct 20 19:57:33 <cjb>	Hello, I'm Chris Ball, an OLPC developer.  I
might disappear during the meeting to relocate to OLPC's office, got
trapped in meetings at home.  :)
Oct 20 19:57:48 <hamstar>	hi chris
Oct 20 19:58:26 <tomeu>	hi all, Tomeu Vizoso here, contracted by OLPC
to work on Sugar
Oct 20 19:58:41 <gbaillie>	hi, I'm Grant Baillie, a Chandler developer
Oct 20 19:59:04 <tomeu>	still in an irc meeting that is (hopefully)
about to finish
Oct 20 19:59:22 <JeffreyH>	hi folks, I'm Jeffrey Harris, a Chandler  
developer
Oct 20 19:59:34 <hamstar>	I'm Mimi Yin, Designer
Oct 20 19:59:36 -->	marcopg
(n=marco-/7XndZFVJGhffOF9BkhkjrY+P9BY0Qu30kFSjKdeMbZ7JUU4I+EOGkB+BqqeVXzbXqFh9Ls21Oc@public.gmane.org) has joined
#sugar-meeting
Oct 20 19:59:39 <hamstar>	for Chandler ;)
Oct 20 19:59:41 <bemasc>	OLPC has a few too many meetings... a
familiar problem, I'm sure
Oct 20 19:59:56 <JeffreyH>	too many is in the eye of the beholder
Oct 20 20:00:37 <JeffreyH>	IRC meetings are less burdensome than face
to face meetings, although they don't have the same emotional bond
building capacity...
Oct 20 20:00:40 <tomeu>	the ones in irc are easier to handle ;)
Oct 20 20:00:46 <JeffreyH>	jinx ;)
Oct 20 20:01:03 <cjb>	yeah, IRC lets me be in two meetings at once,
like right now.
Oct 20 20:01:21 <cjb>	(the previous one was actually rescheduled to
make time for this one, so I should yell at people to finish up.)
Oct 20 20:01:34 <tomeu>	perhaps we could start the meeting with a
summary of the history of each project?
Oct 20 20:01:44 <tomeu>	sugar's one is quite short ;)
Oct 20 20:02:36 <gbaillie>	sure, though Chandler's isn't
Oct 20 20:03:44 <cjb>	tomeu: go for it :)
Oct 20 20:04:03 <tomeu>	marcopg has been around since pretty much the  
beginning
Oct 20 20:04:13 <tomeu>	even since sugar was green ;)
Oct 20 20:05:08 <bemasc>	I wasn't here in the beginning, so to me the
history is prett simple.
Oct 20 20:05:34 <bemasc>	The people who founded OLPC wanted to make a
really cheap laptop, which meant it couldn't run any standard desktop,
because it wouldn't have enough memory/CPU/disk.
Oct 20 20:06:10 <bemasc>	They also wanted to provide an operating
environment designed for learning, and specifically for their vision
of exploratory, freeform learning.
Oct 20 20:06:55 <bemasc>	So they decided to write a new desktop, using
GTK (because it is mature and support i18n well) and Python (because
it allows students to explore and modify the code).
Oct 20 20:07:04 <JeffreyH>	here here
Oct 20 20:07:41 <bemasc>	Sugar is the result of that.  eben is the
lead UI designer, and tomeu and marcopg wrote most of the code.
Oct 20 20:08:01 <bemasc>	There is also a team at Pentagram that has
worked on visual/graphic design for the UI
Oct 20 20:08:34 <JeffreyH>	where is everyone, geographically?
Oct 20 20:08:46 <bemasc>	Boston
Oct 20 20:08:53 <bemasc>	(I mean myself.)
Oct 20 20:09:07 <JeffreyH>	(San Francisco Bay Area for gbaillie and me)
Oct 20 20:09:27 <tomeu>	Prague, CR
Oct 20 20:09:55 <cjb>	(Cambridge, MA here.)
Oct 20 20:09:56 <tomeu>	most of the sugar team is remote: .it, .de,
.za, .in, .cz
Oct 20 20:10:31 <eben>	Cambridge myself, as well, though I live in
Providence these days.
Oct 20 20:11:19 <tomeu>	erikos (Simon Schampijer) has also made big
contributions to the Sugar shell (the desktop, we could say)
Oct 20 20:11:47 <tomeu>	there have been other RedHat employees working
on Sugar at some points
Oct 20 20:11:56 <tomeu>	but now is only Marco
Oct 20 20:12:18 <erikos>	hello from me from germany
Oct 20 20:13:04 <bemasc>	So my initial question is: can we use
Chandler to get a calendar for Sugar?
Oct 20 20:13:18 <bemasc>	currently, we have no calendar/scheduling
capability at all
Oct 20 20:13:41 <JeffreyH>	obviously there's more too it than this
Oct 20 20:13:51 <JeffreyH>	but at first approximation, yes ;)
Oct 20 20:13:57 <JeffreyH>	to, not too
Oct 20 20:13:57 -->	wastrel (n=wastrel@nylug/member/wastrel) has
joined #sugar-meeting
Oct 20 20:14:17 <bemasc>	On the mailing list, Davor said "XO just
doesn't have the CPU power or memory to
Oct 20 20:14:20 <bemasc>	run Chandler. "
Oct 20 20:14:28 <JeffreyH>	At the moment, we've got a 600 line or so
calendar UI that's pure wx
Oct 20 20:14:45 <JeffreyH>	it doesn't take much memory (of course I'm
measuring on a machine with 2GB of RAM)
Oct 20 20:15:03 <tomeu>	sounds pretty slim
Oct 20 20:15:12 <cjb>	neat.
Oct 20 20:15:13 <tomeu>	JeffreyH: how feature complete do you  
consider it?
Oct 20 20:15:14 <bemasc>	The XO has 256 MB total, and our software
isn't so efficient, so we only have about 116 MB free.
Oct 20 20:15:34 <JeffreyH>	there's no model for recurrence or anything
like that in that, it's part of a proof of concept for our
rearchitecture project
Oct 20 20:15:40 <tomeu>	bemasc: I think we use 116MB
Oct 20 20:15:49 <bemasc>	tomeu: ok.  140 MB free.
Oct 20 20:15:51 <tomeu>	yup
Oct 20 20:15:53 <eben>	Do we support wx?  I recall there being some
talk about it when someone tried to port logo, and I never heard the
result.
Oct 20 20:15:57 <tomeu>	still pretty bad ;)
Oct 20 20:16:11 <tomeu>	eben: true, I never heard back
Oct 20 20:16:14 <tomeu>	ucb logo
Oct 20 20:16:17 *	JeffreyH backs up and gives a 5 line Chandler synopsis
Oct 20 20:16:33 <bemasc>	eben: My hunch is that wx should be easy
enough, since wx is a wrapper for GTK (from our perspective).
Oct 20 20:16:47 -->	unmadindu (n=sayamind@gnu-india/admin/unmadindu)
has joined #sugar-meeting
Oct 20 20:16:58 <JeffreyH>	Chandler started as an
Agenda-for-the-new-millenium, which could be thought of as a PIM
construction kit
Oct 20 20:17:10 <bemasc>	(Agenda as in Lotus Agenda)
Oct 20 20:17:17 <JeffreyH>	a book got written,
http://www.dreamingincode.com/ (note that we're on quite good terms
with Scott, we like his book)
Oct 20 20:17:39 <tomeu>	that's good ;)
Oct 20 20:17:41 <JeffreyH>	a PIM construction kit was hard, rather
than drown in the ocean, we focused in on events, task lists, focus
management, and small group sharing/collaboration
Oct 20 20:17:51 <cjb>	I think some of us have read the book -- I heard
a 20-minute interview with Scott, but haven't read it yet.
Oct 20 20:18:23 <JeffreyH>	We realized a year or two ago that the
legacy architecture for PIM construction kit was too big a behemoth,
started working on Trellis based, testable, "Humble UI".
rearchitecture or rearch for short
Oct 20 20:18:29 <cjb>	eben: We don't like Wx very much because the
core of Sugar does things like provide toolbars and widgets that use
GTK, and you won't get access to those in Wx.
Oct 20 20:18:37 <cjb>	But other than that.. could be worse, etc.
Oct 20 20:18:49 <cjb>	JeffreyH: What's Trellis?
Oct 20 20:18:52 <JeffreyH>	at this point, we've got old architecture,
Chandler 1.0, which works, but it has performance issues
Oct 20 20:18:59 <eben>	cjb: I see...that would pose some problems.
Oct 20 20:19:04 <JeffreyH>	http://peak.telecommunity.com/DevCenter/ 
Trellis
Oct 20 20:19:20 <JeffreyH>	pretty nifty.  I don't think we've proved
it scales well yet, but I'm excited about it
Oct 20 20:19:32 <JeffreyH>	(don't know if gbaillie would agree with
that description)
Oct 20 20:19:40 <cjb>	eben: in short, you'd end up with something
similar to etoys, I think -- sort of integrated but not quite.
Oct 20 20:19:42 <JeffreyH>	that's Chandler in a nutshell :)
Oct 20 20:19:48 <eben>	cjb: right.
Oct 20 20:19:51 <cjb>	JeffreyH: thanks!
Oct 20 20:20:13 <eben>	I'd prefer to limit those instances, when at
all possible.
Oct 20 20:20:22 <cjb>	JeffreyH: (to avoid issues with running Wx, do
you have a webapp version we could run locally instead?)
Oct 20 20:20:27 <gbaillie>	(i'd agree pretty much, JeffreyH)
Oct 20 20:20:33 *	m_stone notes, quietly, that he is now present.
Oct 20 20:20:45 <bemasc>	eben: I tend to expect the opposite of cjb.
Because wx renders through GTK, our themes would apply automatically
to an wx application.
Oct 20 20:20:57 <cjb>	bemasc: toolbar = Activity.Toolbar()
Oct 20 20:21:11 <eben>	bemasc: themes, probably, but what about our
custom widgets?
Oct 20 20:21:12 <hamstar>	hi, just wanted to add something to
JeffreyH's description
Oct 20 20:21:18 <bemasc>	cjb: that seems easy enough to throw in.  I'm
not suggesting running Chandler unmodified.
Oct 20 20:21:32 <cjb>	ok.  I agree with bemasc that we certainly
shouldn't dismiss the possibility out of hand.
Oct 20 20:21:42 *	hamstar woops will wait for a break
Oct 20 20:21:50 <cjb>	JeffreyH: oh, neat, this is a little like the
reactive functional programming stuff.
Oct 20 20:21:56 <bemasc>	hamstar: please continue.
Oct 20 20:22:01 <hamstar>	hi
Oct 20 20:22:03 <JeffreyH>	cjb: Yeah, I forgot to mention as part of
the nutshell that Chandler is both a desktop application and a server
for sharing, with a web ui on top of the server
Oct 20 20:22:17 <hamstar>	so i realize that the focus right now for
you guys is calendaring?
Oct 20 20:22:22 <m_stone>	hamstar: not quite.
Oct 20 20:22:24 <hamstar>	(apologies if that is oversimplifying)
Oct 20 20:22:29 <m_stone>	hamstar: we're also deeply interested in  
the sharing.
Oct 20 20:22:29 <hamstar>	ok go ahead
Oct 20 20:22:35 <hamstar>	ok
Oct 20 20:22:36 <cjb>	hamstar: hm, not necessarily.  we don't have any
kind of calendar/PIM/stuff, so I think everything you have is
interesting.
Oct 20 20:22:39 *	JeffreyH reads back for a minute, there's a lot
going on, which is good ;)
Oct 20 20:22:43 <hamstar>	ha
Oct 20 20:22:44 <cjb>	oh, yes, we like to share.  ;-)
Oct 20 20:22:45 <hamstar>	well so
Oct 20 20:22:50 <hamstar>	so i guess for chandler
Oct 20 20:22:53 -->	moondawg
(n=chatzill-I3Wj4syaC+4vP6DCt/[email protected]) has joined
#sugar-meeting
Oct 20 20:23:00 <hamstar>	in the same way that sugar positions  
functionality
Oct 20 20:23:04 <hamstar>	as activities as opposed to apps
Oct 20 20:23:16 <hamstar>	calendaring in chandler...is not really a
free-standing thing in and of itself
Oct 20 20:23:31 <hamstar>	but is one piece in a larger notion of focus
management
Oct 20 20:23:36 <hamstar>	or organizing information
Oct 20 20:23:46 <hamstar>	in that sense "chandler" as a verb
Oct 20 20:23:57 <hamstar>	is really the "organize" or "manage" acitvity
Oct 20 20:24:06 <hamstar>	and scheduling things on a calendar is one
of the ways to do that
Oct 20 20:24:09 <hamstar>	but really, the triage list
Oct 20 20:24:16 <hamstar>	is the central point of entry - point of  
return
Oct 20 20:24:18 <hamstar>	for the app
Oct 20 20:24:30 <hamstar>	does that make sense?
Oct 20 20:24:32 <m_stone>	"triage list" sounds a bit like "journal"...
Oct 20 20:24:33 *	JeffreyH looks for a few screenshots
Oct 20 20:24:34 <cjb>	I see.  So you're saying the calendar is
somewhere that information can end up, but that's not the point of
gathering the information in the first place.
Oct 20 20:24:50 <m_stone>	but future-facing rather than past-facing.
Oct 20 20:25:02 <hamstar>	well it's past, present and future
Oct 20 20:25:11 <m_stone>	hamstar: is your sharing interactive or  
batch-based?
Oct 20 20:25:14 <hamstar>	it's a time-based view
Oct 20 20:25:21 <hamstar>	you mean real-time?
Oct 20 20:25:23 <tomeu>	m_stone: actually the HIG calls for the
journal to be able to deal with notes in the future
Oct 20 20:25:23 <hamstar>	or asynchronous?
Oct 20 20:25:38 <bemasc>	tomeu: but nobody's ever worked out how that
should work.
Oct 20 20:25:39 <JeffreyH>	yes, m_stone.  gbaillie and I were
discussing Sugar before this meeting started, we didn't quickly find
APIs for the Journal (though we didn't search that hard).  I'm not
clear on how much the Journal is aimed at being a history, and how
much it's meant to be an edited-by-the-user focus point
Oct 20 20:25:53 <eben>	m_stone: indeed.  I had some ideas written up
about building future events into the Journal, as calendar entries,
optionally with alarms.
Oct 20 20:25:55 <hamstar>	there is overlap between chandler and journal
Oct 20 20:25:57 <tomeu>	bemasc: well, adding reminders should be quite
straightforward, isn't it?
Oct 20 20:26:08 <bemasc>	tomeu: it's far from obvious to me.
Oct 20 20:26:17 <hamstar>	this is a screenshot
Oct 20 20:26:18 <m_stone>	hamstar: git is a prototypical model of what
I mean by 'batch-based'.
Oct 20 20:26:19 <hamstar>	of the triage list
Oct 20 20:26:20
<hamstar>	http://chandlerproject.org/pub/Projects/ProductTour/ 
windows_triagelist.png
Oct 20 20:26:27 <m_stone>	hamstar: as opposed to, say, google docs.
Oct 20 20:26:43 *	JeffreyH suspects that since hamstar isn't a git
user, that doesn't mean much to her :)
Oct 20 20:26:50 <hamstar>	heh
Oct 20 20:27:00 <bemasc>	m_stone: it's batch-based, all over SMTP, IIUC.
Oct 20 20:27:21 <hamstar>	so conceptually, journal is a log of
everything you're doing through time
Oct 20 20:27:26 <hamstar>	calendar is your schedule through time
Oct 20 20:27:28 <hamstar>	the triage list
Oct 20 20:27:33 <hamstar>	is more like, irrespective of time
Oct 20 20:27:40 <hamstar>	what do i want to be focusing on?
Oct 20 20:27:51 <m_stone>	hamstar: the screenshot communicated the
purpose quite well.
Oct 20 20:27:58 <hamstar>	:)
Oct 20 20:28:15 <Hyakugei>	m_stone - the sharing, which is done via
the server (although there is also sharing via email) is done async.
Oct 20 20:28:36 *	Hyakugei just a chandler user
Oct 20 20:28:38 *	eben notes as an aside to bemasc that he thinks
reminders/calendar entries would be fairly straightforward to add.
Oct 20 20:28:41 <m_stone>	compare with
http://wiki.laptop.org/go/Designs/Journal and
http://wiki.laptop.org/go/Journal%2C_reloaded
Oct 20 20:28:45 <tomeu>	I love that focus management thing, that's  
what I need!
Oct 20 20:28:51 <cjb>	:)
Oct 20 20:29:17 <hamstar>	the asynchronous nature of sharing in chandler
Oct 20 20:29:29 <hamstar>	is meant to fill the gap between real-time
meetings / chat sessions and email
Oct 20 20:29:33 <JeffreyH>	Our sharing model is very batch based, not
necessarily over SMTP, usually these days over a custom HTTP protocol
to our server, representing changes as diffs.
Oct 20 20:29:36 <hamstar>	so that people can work on the same things
in dribs and drabs
Oct 20 20:29:40 <hamstar>	throughout their day
Oct 20 20:29:52 <bemasc>	interesting
Oct 20 20:29:59 <hamstar>	so you could imagine 2 students working on a
hw assignment
Oct 20 20:30:00 <hamstar>	homework
Oct 20 20:30:03 <bemasc>	we have done a lot of work on continuous
real-time collaboration
Oct 20 20:30:06 <hamstar>	and each contributing ideas
Oct 20 20:30:10 <bemasc>	and very little on "async" collaboration
Oct 20 20:30:11 <tomeu>	bemasc++
Oct 20 20:30:22 <m_stone>	JeffreyH: good to know. to date, we've
concentrated heavily on the real-time no-divergence sharing problems.
Oct 20 20:30:29 <cjb>	yeah, that's true.  (we have collaborative word
processing and things like that.
Oct 20 20:30:29 <hamstar>	of course, we would love it if chandler
could do synchronous stuff too
Oct 20 20:30:44 <tomeu>	bemasc: async collaboration would be done with
entry sharing and some activity-dependent merging support
Oct 20 20:30:59 <m_stone>	tomeu: so goes the theory, anyway. :)
Oct 20 20:31:01 <bemasc>	tomeu: there are many ways it could be done
Oct 20 20:31:12 <tomeu>	m_stone: well, it's already done by that
Oct 20 20:31:15 <m_stone>	hamstar: we've also paid a lot of attention
to presence technology.
Oct 20 20:31:18 <tomeu>	m_stone: just that quite crudely
Oct 20 20:31:40 <tomeu>	we should grow some more support for async  
sharing
Oct 20 20:31:52 <m_stone>	hamstar: mainly divided up by network
environment -- w/ server, ethernet w/out server, and wifi w/out
server.
Oct 20 20:31:59 <hamstar>	presence would be really neat actually
Oct 20 20:32:03 <hamstar>	combined with asynchronous stuff
Oct 20 20:32:08 <hamstar>	meaning even if someone is offline
Oct 20 20:32:11 <hamstar>	you could see the last thing they did
Oct 20 20:32:16 <eben>	shared calendar activities seem pretty
straightforward in the Sugar model; it would just be a shared calendar
a la Gcal or something.
Oct 20 20:32:18 <hamstar>	sort of a ghost presence ;)
Oct 20 20:32:30 <JeffreyH>	it's actually kind of amazing to me how
much we're working in the same space, but how little overlap we have.
While we're interested in presence/real time stuff, we've done nothing
with it
Oct 20 20:32:40 <tomeu>	hamstar: empathy in GNOME would help with
presence, but is not as portable as you'd like :/
Oct 20 20:32:44 <JeffreyH>	I *think* that's a good thing ;)
Oct 20 20:33:01 <tomeu>	;)
Oct 20 20:33:04 <m_stone>	JeffreyH: it's a big space...
Oct 20 20:33:11 <JeffreyH>	indeed
Oct 20 20:33:15 <JeffreyH>	I want to back up for a second and talk
about wx vs. gtk
Oct 20 20:33:21 <tomeu>	I'm also interested in how Chandler has been
designing its user experience
Oct 20 20:33:21 <m_stone>	sure.
Oct 20 20:33:28 <bemasc>	The tricky thing about Sugar is that, when
possible, everything is designed to function in the absence of any
server or reliable internet connection.
Oct 20 20:33:36 <tomeu>	I understand you weren't just cloning an
existing closed source app
Oct 20 20:33:40 <JeffreyH>	and note that our rearch project is pretty
explicitly focused on not making the domain and interaction models
dependent on any specific presentation
Oct 20 20:33:41 <m_stone>	bemasc: and with users who can't read.
Oct 20 20:33:43 *	hamstar we can touch on that after this tomeu
Oct 20 20:34:15 <JeffreyH>	So, the fact that we've got an Apache
licensed  wx proof-of-concept calendar UI
Oct 20 20:34:32 <gbaillie>	i'm somewhat curious as to what kind of
calendar you want for your users
Oct 20 20:34:38 <JeffreyH>	was really meant as a place-holder for
"we've put a lot of thought/energy into calendar UI" :)
Oct 20 20:35:15 <cjb>	JeffreyH: it sounds like one or a couple of us
should get a chandler build environment and try out your UIs :)
Oct 20 20:35:28 <JeffreyH>	I imagine that to do something similar in
pygtk would be fairly easy, the hard part is figuring out what you
want and how to structure interaction, imho
Oct 20 20:36:06 <m_stone>	that seems plausible to me.
Oct 20 20:36:18 <cjb>	makes sense.  we won't pretend that we know what
we want yet.  ;-)
Oct 20 20:36:57 <JeffreyH>	that'd be great, cjb.  Do note that the
proof-of-concept calendar ui I'm talking about isn't the same as
what's in chandler 1.0.  Oh, and it looks to me like the wx that ships
with Chandler 1.0 OS X is crashing drag and drop pretty reliably still
:(
Oct 20 20:36:57 <bemasc>	One thing that interested me very much was
that the Chandler rearch might use a D-Bus API to access the storage
backend
Oct 20 20:37:39 *	m_stone cries.
Oct 20 20:37:46 <cjb>	heh.
Oct 20 20:38:09 <cjb>	OLPC is divided into people who love dbus and
people for whom every instance of an app speaking dbus is a travesty
of.. something.
Oct 20 20:38:22 <cjb>	JeffreyH: awesome.  do you have a pointer to  
the p-o-c UI?
Oct 20 20:38:46 <tomeu>	I don't love dbus, but think it's inevitable
if we want to play in the GNOME desktop league
Oct 20 20:39:08 <tomeu>	in fact, I wonder if there's someone who
actually loves dbus around
Oct 20 20:39:39 <cjb>	well, bemasc sounded enthusiastic :) anyway.
Oct 20 20:39:46 <gbaillie>	we have (outside) devs who are interested
in doing dbus-y stuff with the rearchitecture code
Oct 20 20:40:17 <bemasc>	I think d-bus is a pretty good way to
communicate with daemons, and daemons are often inevitable when trying
to multiplex access to a central resource.
Oct 20 20:40:57 <JeffreyH>	cjb: getting the env up and running is a
little involved, the source code is
http://svn.osafoundation.org/chandler/branches/rearchitecture/ 
Chandler-Platform/ocap/wxui/calendar_canvas.py.
  Oops, looks like that's 1543 lines, not 800 ;)
Oct 20 20:41:08 <tomeu>	;)
Oct 20 20:41:21 <tomeu>	nice we got it before it's 12000
Oct 20 20:41:28 <cjb>	JeffreyH: yeah, I tried building from source
already, so I know it's involved :)
Oct 20 20:41:36 *	cjb tried on x86-64 Fedora, which is apparently a  
mistake.
Oct 20 20:41:52 <bemasc>	how is chandler with ical/gcal/webcal...?
Oct 20 20:42:57 <cjb>	JeffreyH: oh, interesting, this app is totally
self-contained?
Oct 20 20:43:01 <JeffreyH>	yeah, cjb, getting the 1.0 codebase running
on 32 bit OSes is actually fairly painless, 64 bit, not so much
Oct 20 20:43:05 <cjb>	(i.e. no imports from chandler modules?)
Oct 20 20:43:23 <JeffreyH>	yes, all the rearchitecture stuff doesn't
depend on legacy stuff
Oct 20 20:43:27 <cjb>	ooh
Oct 20 20:43:40 <JeffreyH>	and that module specifically only depends
on wx and PyICU plus a few resource files for graphics
Oct 20 20:43:52 <m_stone>	JeffreyH: tomeu still wants to hear from
hamstar about interaction design, I think.
Oct 20 20:44:02 <hamstar>	hi
Oct 20 20:44:11 <m_stone>	tomeu: could you restate your question?
Oct 20 20:44:47 <tomeu>	just wanted to hear about how chandler decided
which user experience should be given to their users
Oct 20 20:44:57 <tomeu>	I guess that's a bit of history as well
Oct 20 20:45:00 <hamstar>	heh
Oct 20 20:45:11 <hamstar>	well there was certainly a lot of user  
research
Oct 20 20:45:23 <hamstar>	we started with a very vague, generic  
target user
Oct 20 20:45:26 <hamstar>	"info-centric people"
Oct 20 20:45:32 <hamstar>	and gradually narrowed it down
Oct 20 20:45:39 <hamstar>	to be pretty specific
Oct 20 20:45:50 <hamstar>	basically "knowledgeworkers" which we  
define as
Oct 20 20:46:07 <hamstar>	people who consider the output of their work
Oct 20 20:46:18 <hamstar>	to be information itself
Oct 20 20:46:37 <hamstar>	so
Oct 20 20:46:41 <hamstar>	you can be consuming a lot of information
Oct 20 20:46:48 <hamstar>	but if your job is to summarize it
Oct 20 20:46:59 <hamstar>	that's different from
Oct 20 20:47:09 <hamstar>	just someone who is consuming a lot of  
information :)
Oct 20 20:47:28 <hamstar>	for ex, chandler isn't = rss reader
Oct 20 20:47:48 <hamstar>	the workflows were originally designed
Oct 20 20:47:49 <tomeu>	I see
Oct 20 20:48:04 <hamstar>	phew, i realize even our narrowing can sound
generic ;)
Oct 20 20:48:16 <hamstar>	based on what people seemed to be trying to do
Oct 20 20:48:17 <hamstar>	with traditional tools
Oct 20 20:48:19 <hamstar>	like outlook
Oct 20 20:48:20 <hamstar>	and palm
Oct 20 20:48:25 <hamstar>	but had to sort of hack stuff
Oct 20 20:48:28 <hamstar>	to get it to work correctly
Oct 20 20:48:39 <hamstar>	e.g. people had all kinds of weird things
they did with flagging email
Oct 20 20:48:44 <m_stone>	tomeu: sounds like me.
Oct 20 20:48:46 <hamstar>	or emailing stuff to themselves
Oct 20 20:48:57 <hamstar>	so chandler is designed to do those things
more naturally
Oct 20 20:49:00 <cjb>	JeffreyH: (ah, I need ocap.wxui.* too)
Oct 20 20:49:13 <hamstar>	like instead of emailing yourself, you can
set a tickler alarm to have something come back into NOW later
Oct 20 20:49:23 <hamstar>	or instead of cutting and pasting email info
onto your calendar,
Oct 20 20:49:30 <hamstar>	you just "stamp it" and put it directly onto
the calendar
Oct 20 20:49:46 <hamstar>	we did a lot of lightweight usability testing
Oct 20 20:49:51 <hamstar>	before the preview release
Oct 20 20:49:56 <hamstar>	but since preview, we've mostly
Oct 20 20:50:11 <hamstar>	made our design decisions from processing
and interacting with the user community
Oct 20 20:50:21 *	tomeu would like to hear a bit more about usability  
testing
Oct 20 20:50:30 <hamstar>	so the testing
Oct 20 20:50:34 <JeffreyH>	bemasc: re:iCal, early on in my tenure at
OSAF I wrote a Python iCalendar library.  For the most part Chandler's
integration with iCal is good, although our defaults are a little
focused on failing when something goes wrong, really for 1.0 I
probably should've changed those to warnings (there's a lot of invalid
iCal out there)
Oct 20 20:50:35 <hamstar>	spanned conceptual tests
Oct 20 20:50:44 <hamstar>	like, do people get the idea of traiging
Oct 20 20:50:45 <hamstar>	triaging
Oct 20 20:50:49 <hamstar>	we just set up buckets
Oct 20 20:50:58 <JeffreyH>	gCal is basically iCal with recurrence
broken beyond recognition, so we work fine with gCal as long as
there's no recurrence
Oct 20 20:51:02 <hamstar>	and did sorting exercises with made up tasks
Oct 20 20:51:09 <hamstar>	or we had people do a braindump of what was
on their mind
Oct 20 20:51:20 <hamstar>	we also did "interaction" tests
Oct 20 20:51:24 <hamstar>	to fine-tune things like
Oct 20 20:51:28 <hamstar>	the stamping buttons
Oct 20 20:51:36 <hamstar>	to star notes and put them on the calendar
or address them
Oct 20 20:51:59 <hamstar>	it was all pretty simple
Oct 20 20:52:04 <hamstar>	a lot of paper prototyping
Oct 20 20:52:17 <hamstar>	and then of course testing on the app
Oct 20 20:52:24 <tomeu>	hamstar: where did you got people to play with?
Oct 20 20:52:33 <bemasc>	hamstar: where did you do these tests? Did
you post flyers "software testers wanted" or...?
Oct 20 20:52:37 <hamstar>	well mostly through friends
Oct 20 20:52:43 <hamstar>	no more word of mouth
Oct 20 20:52:46 <tomeu>	did you had professional QA people?
Oct 20 20:52:48 <hamstar>	we've participated in a number of
Oct 20 20:52:51 <hamstar>	FLOSS events
Oct 20 20:52:57 <hamstar>	they've helped find test subjects too
Oct 20 20:53:04 <hamstar>	we had a QA team up until January
Oct 20 20:53:10 <hamstar>	but that was less usability testing
Oct 20 20:53:30 <hamstar>	and more - is the app doing what it's
supposed to be doing?
Oct 20 20:53:41 <hamstar>	in the end, i think the most valuable
testing we've gotten
Oct 20 20:53:48 <hamstar>	is live, "in the field" testing by users
Oct 20 20:53:56 <tomeu>	interesting
Oct 20 20:54:04 <hamstar>	they give us feedback on workflow issues
Oct 20 20:54:11 <hamstar>	that are hard to get at, in isolated test  
sessions
Oct 20 20:54:19 <hamstar>	because people aren't really in their
"natural work mode"
Oct 20 20:54:27 <tomeu>	hamstar: who helps developers convert that
information into modifications to the code?
Oct 20 20:54:43 <hamstar>	i guess me and sheila
Oct 20 20:54:52 <hamstar>	but more recently, i think the devs
Oct 20 20:54:57 <hamstar>	have had a more hands-on approach
Oct 20 20:55:00 <cjb>	(hm, I really have to relocate -- I'll catch up
on the backlog once I get to work, please keep going.)
Oct 20 20:55:01 <hamstar>	to interacting with users directly
Oct 20 20:55:09 <bemasc>	unfortunately, our users are eight years old,
4000 miles away, don't speak English, don't have a network connection,
and don't have an e-mail client.
Oct 20 20:55:13 <hamstar>	and we discuss solutions together
Oct 20 20:55:20 <hamstar>	yes, we are lucky
Oct 20 20:55:21 <cjb>	JeffreyH: would be interested to hear if I can
get ocap.wxui.* without too many other deps.
Oct 20 20:55:30 <hamstar>	that our users email all day long, it's  
their job ;)
Oct 20 20:55:33 <bemasc>	so we have lots of users and only a trickle
of feedback, much of which is hard to interpret.
Oct 20 20:55:34 <cjb>	bemasc: that was a good way to put it :)
Oct 20 20:55:41 <tomeu>	bemasc: true, but they have teachers, which
help quite a bit
Oct 20 20:55:53 <hamstar>	is video out of reach?
Oct 20 20:56:03 <cjb>	tomeu: some of them have teachers some of the  
time :)
Oct 20 20:56:04 <tomeu>	I think we can build a community where
developers are not so far away from the real users
Oct 20 20:56:20 <tomeu>	cjb: we don't need to hear a billion of kids
at the same time ;)
Oct 20 20:56:40 <JeffreyH>	cjb: I think you basically need to checkout
http://svn.osafoundation.org/chandler/branches/rearchitecture/ 
Chandler-Platform/
and run setup.py develop.  But it's possible Chandler-Platform depends
on something else in
http://svn.osafoundation.org/chandler/branches/rearchitecture/  Also,
you need wx and PyICU.
Oct 20 20:56:49 <bemasc>	hamstar: Sugar includes a video recording
activity (called Record), but it's very limited
Oct 20 20:56:57 <cjb>	JeffreyH: excellent, thanks, got the latter two  
already.
Oct 20 20:57:17 <bemasc>	we also don't yet have an easy way to send
things (like videos) over the network.
Oct 20 20:57:18 <hamstar>	it records the screen?
Oct 20 20:57:28 <bemasc>	hamstar: no, it records from the built-in  
videocamera
Oct 20 20:57:29 <cjb>	no, we have a video camera in the laptop
Oct 20 20:57:32 <hamstar>	oh cool right
Oct 20 20:57:40 <cjb>	people sometimes post things to youtube from  
their laptops
Oct 20 20:58:05 <cjb>	e.g. http://www.youtube.com/watch?v=BOzBTGGVWNg :)
Oct 20 20:58:06 <bemasc>	hamstar: cjb actually just built a little
video-screen-capture activity, but it hasn't been distributed
Oct 20 20:58:12 <JeffreyH>	so, how long do sugar meetings usually
last?  Don't want to exhaust everyone ;)
Oct 20 20:58:29 <bemasc>	we should probably follow up some other time
Oct 20 20:58:29 <cjb>	JeffreyH: until we get to the magic Action  
Items stage!
Oct 20 20:58:35 <hamstar>	you know
Oct 20 20:58:44 <bemasc>	cjb is right
Oct 20 20:58:50 <bemasc>	which means it's time for Action Items
Oct 20 20:58:56 *	cjb drumroll
Oct 20 20:59:13 <bemasc>	so... who wants to do something?
Oct 20 20:59:22 <bemasc>	cjb is getting Chandler building
Oct 20 20:59:26 <cjb>	I'll get the rearch UI built
Oct 20 20:59:29 <hamstar>	so you won't get at the usability issues
that come from cultural differences...but watching american kids will
get at workflow issues
Oct 20 20:59:38 <tomeu>	JeffreyH: it's a bit late for the people in  
europe :/
Oct 20 20:59:38 <cjb>	no promises about full Chandler ;-)
Oct 20 20:59:52 <bemasc>	m_stone: does chandler 1.0 sound like your
collaborative mailing list summarizer...?
Oct 20 21:00:23 *	hamstar wow that is quite a video
Oct 20 21:00:28 <bemasc>	JeffreyH: is the rearch stuff being
documented somewhere?
Oct 20 21:00:38 <m_stone>	bemasc: I was thinking of a realtime  
system. :)
Oct 20 21:00:42 <bemasc>	the only page I saw was ... extremely vague
Oct 20 21:00:44 <m_stone>	bemasc: but there are certain similarities.
Oct 20 21:00:56 <cjb>	hamstar: it was taken by an
apparently-very-patient ten year old boy in Uruguay :)
Oct 20 21:00:56 <JeffreyH>	I'm interested in talking a little more
about whether/ how one goes about linking to a document in Sugar at
some point
Oct 20 21:01:23 <bemasc>	JeffreyH: Sugar, at the moment, provides no
way for one document to refer to another
Oct 20 21:01:35 <bemasc>	and actively discourages people from  
attempting this
Oct 20 21:01:47 <m_stone>	(though we're currently debating some ways
to change that)
Oct 20 21:01:56 <bemasc>	because documents are designed to be passed
over the network, and keeping track of references between them over an
unreliable network is terrifying
Oct 20 21:02:10 <m_stone>	bemasc: I don't think that's the reason.
Oct 20 21:02:18 <JeffreyH>	bemasc: our process for rearch is to do
doctest-first development.  So we have a series of pretty readable,
but collectively not yet organized, doctests.  They can be built with
Sphinx into cross-referenced documentation, we don't have that
automated yet, but we could, if you're a likely consumer ;)
Oct 20 21:02:30 <tomeu>	bemasc: you can reference just fine, just that
there you are on your own ;)
Oct 20 21:02:42 <bemasc>	I think Chandler's capabilities make most
sense as part of the core system
Oct 20 21:02:48 <bemasc>	but it's not clear where, exactly
Oct 20 21:03:28 <bemasc>	one possibility would be, since we are all
building "temporally organized information retrieval systems", to
agree upon an API there
Oct 20 21:03:36 <bemasc>	or even share a backend for certain things
Oct 20 21:04:01 <bemasc>	but our approaches so far have been quite
different, with Sugar taking a very filesystem-like approach, and
Chandler taking a very e-mail-like approach
Oct 20 21:04:20 <tomeu>	I would start by just explaining the trade
offs we made and which was our experience
Oct 20 21:04:43 <tomeu>	we can already learn a lot by just that
Oct 20 21:04:54 <m_stone>	I agree with tomeu.
Oct 20 21:05:05 <tomeu>	and will know more about the feasibility of  
sharing code
Oct 20 21:05:09 <m_stone>	For example, I'm quite interested in the
performance work you've tried to do with your rearch.
Oct 20 21:05:10 <JeffreyH>	re: linking, sensible, but a little sad,
bemasc.  Chandler's organization approach would be enhanced by easily
creating an item that links to some document (or some other context,
whatever that means).  Doesn't work very well on the big 3 desktops
now, though, so nothing lost, just nothing gained ;)
Oct 20 21:06:15 <tomeu>	performance++
Oct 20 21:06:38 <JeffreyH>	hmm, I should probably clarify
Oct 20 21:06:45 <JeffreyH>	that there are really 3 projects floating  
around
Oct 20 21:06:49 <JeffreyH>	in the chandler sphere
Oct 20 21:07:01 <JeffreyH>	1. Chandler 1.0 codebase, legacy, works, slow
Oct 20 21:07:29 <hamstar>	(usable ;)
Oct 20 21:07:58 <JeffreyH>	2. first stab at rearchitecture (the svn
links I gave above were to that codebase) which was mostly about
demonstrating that a wx UI could be snappier than chandler 1.0 and
more nicely modular
Oct 20 21:08:19 <JeffreyH>	3. chandler2 codebase (also, confusingly,
called rearchitecture, I just realized the confusion there, sorry)
Oct 20 21:08:29 <JeffreyH>	which is what gbaillie and I are actively
working on right now
Oct 20 21:08:35 <gbaillie>	we have done some perf work on all
Oct 20 21:08:45 <cjb>	have you found any general themes in your python
performance work?
Oct 20 21:08:49 <JeffreyH>	we're focusing on the domain and
interaction models for chandler2 right now, we don't have any ui wired
up
Oct 20 21:08:54 <cjb>	we need to do quite a lot of it
Oct 20 21:08:59 <cjb>	and often don't know where to start :)
Oct 20 21:09:03 <gbaillie>	though, 3 is mainly checking that things
don't go too far out the window in extreme cases (like reminders)
Oct 20 21:09:04 <--	erikos has quit (Remote closed the connection)
Oct 20 21:09:38 <gbaillie>	back in the day, we did a lot of perf work  
on 1
Oct 20 21:09:55 <gbaillie>	mainly, running slow-seeming scenarios in
profiler, etc.
Oct 20 21:10:08 <bemasc>	gbaillie: which profiler?
Oct 20 21:10:08 <gbaillie>	most of the memory work we did was looking
at things like leaks
Oct 20 21:10:18 <gbaillie>	oh, mostly hotshot
Oct 20 21:10:20 <bemasc>	gbaillie: what tools did you use to look for  
leaks?
Oct 20 21:10:30 <gbaillie>	some people used valgrand iirc
Oct 20 21:10:43 <gbaillie>	i would have to go back and look
Oct 20 21:10:56 <tomeu>	gbaillie: guppy's heapy worked pretty well  
for us
Oct 20 21:11:02 <tomeu>	for python leaks
Oct 20 21:11:05 <gbaillie>	(i seem to remember heikkit -- not in this
meeting -- having done that)
Oct 20 21:11:08 <gbaillie>	huh
Oct 20 21:11:35 <gbaillie>	someone else did some stuff with tools i
don't remember
Oct 20 21:11:46 <gbaillie>	you had to build a new python interpreter
Oct 20 21:11:53 <gbaillie>	to instrument everything
Oct 20 21:11:57 <JeffreyH>	really, we didn't focus much on memory
footprint, raw cpu cycles performance was much more of a concern for
us on the spacious platforms we were targetting
Oct 20 21:12:04 <tomeu>	yeah, for valgrind you need to rebuild python
Oct 20 21:12:38 <tomeu>	I'm sorry to have to leave :(
Oct 20 21:13:08 <JeffreyH>	well, it seems like there's probably room
for more conversation.  bemasc, perhaps an action item is to schedule
a follow up meeting?
Oct 20 21:13:11 <gbaillie>	we could re-convene @ some pt
Oct 20 21:13:15 <m_stone>	that would be good.
Oct 20 21:13:18 <tomeu>	I will join #chandler and pop up when I see a
topic that rings something in sugar
Oct 20 21:13:32 <m_stone>	bemasc: will you please schedule another  
meeting?
Oct 20 21:13:41 <bemasc>	m_stone: I'd be happy to.
Oct 20 21:13:44 <tomeu>	bemasc: pretty please? ;)
Oct 20 21:13:47 <tomeu>	nice
Oct 20 21:14:26 <bemasc>	ok... I think that's it.
Oct 20 21:14:27 <JeffreyH>	bemasc: we should talk more about storage
APIs.  One of the things we've left wide open in rearch is how we'll
do persistence, I think it's plausible we could work together there
Oct 20 21:14:38 <JeffreyH>	(not now, just noting items for future  
meeting ;)
Oct 20 21:14:41 <bemasc>	JeffreyH: that's interesting.
Oct 20 21:14:58 <JeffreyH>	bemasc: I
Oct 20 21:15:11 <m_stone>	JeffreyH: perhaps. one of the people who has
thought most about this is in Peru for the week, but will be back
afterward.
Oct 20 21:15:13 <tomeu>	yup, we have had lots of discussions about that
Oct 20 21:15:20 <JeffreyH>	I'll take an action item of putting most
recent documentation up somewhere globally readable
Oct 20 21:15:24 <gbaillie>	are there any online docs about storage?
Oct 20 21:15:29 <m_stone>	http://wiki.laptop.org/go/Olpcfs
Oct 20 21:15:42 <m_stone>	this is one class of idea we have considered.
Oct 20 21:15:53 <gbaillie>	great, thanks
Oct 20 21:15:57 <m_stone>	Scott wrote the paper and then wrote up a
demo implementation which you can try out if you want.
Oct 20 21:16:02 <bemasc>	gbaillie:
http://wiki.laptop.org/go/Low-level_Activity_API#Datastore
Oct 20 21:16:09 <bemasc>	I think that's the current state of things.
Oct 20 21:16:31 <m_stone>	but the social circumstances which created
it are rather complex and, post implementation, Scott has come to the
conclusion that he wouldn't ship it.
Oct 20 21:16:46 <m_stone>	(as I understand it), primarily because he
thinks its inadequately modular.
Oct 20 21:17:01 <bemasc>	gbaillie: and
http://wiki.laptop.org/go/Journal_reloaded is the most recent proposal
Oct 20 21:17:03 <m_stone>	anyway, read that and you'll be well
prepared to chat with us at our next meeting.
Oct 20 21:17:17 <gbaillie>	i'll do that, and thanks again
Oct 20 21:17:19 <m_stone>	(similarly, send us any pages you'd like us  
to read)
Oct 20 21:17:37 <cjb>	also, I'll try and get a pointer to a
working/useful livecd to try out for the next meeting
Oct 20 21:17:42 <bemasc>	I'll write up a wiki page to brainstorm
questions for next meeting
Oct 20 21:18:06 <cjb>	(I just tried out the debian one, it's missing a
lot of stuff.)
Oct 20 21:18:10 <--	Hyakugei (i=user-k8YVW5E0GziI6eSDoErcOrZkRJXU5yhkaG28LS4vraQ@public.gmane.org)
has left #sugar-meeting
Oct 20 21:18:30 <bemasc>	ok.... Adjourned!

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev