]> git.zerfleddert.de Git - micropolis/blob - src/notes/OLPC-notes.txt
resize editor when resizing window
[micropolis] / src / notes / OLPC-notes.txt
1 Micropolis for OLCP Sugar User Interface
2 By Don Hopkins (dhopkins@DonHopkins.com)
3
4 Why is Micropolis such a great match for OLPC's Sugar interface?
5
6 Constructivist education.
7 Children learn by doing and experiencing.
8 Playful learning (as opposed to edutainment).
9 People learn effectively through making things.
10 Micropolis is often mentioned as a great example of an educational,
11 constructivist game, in the academic literature and popular press.
12
13 Multi player
14 Sharing, collaborating, conferencing, voting.
15
16 Writing journals about Micropolis
17 The Micropolis Journal: newspaper metaphore.
18
19 Drive the development and prove the worthyness of the technology.
20
21 Develop Micropolis hand-in-hand with Sugar, so they synergize with each other.
22
23 I developed the HyperLook version of Micropolis in parallel with the
24 HyperLook user interface environment, and they both were better
25 because of it. Micropolis required HyperLook to support useful
26 multimedia extensions like a shared audio mixer server, an efficient
27 shared memory based bitmap animation system, and integration with
28 TNT Open Look user interface components (sliders, pin-up menus,
29 buttons, etc). And Micropolis was able to take full advantage of
30 HyperLook's features like outline graphics, scaling images,
31 graphical editing, printing PostScript, etc. Micropolis was extremely
32 useful as an engaging promotional demonstation that proved the
33 capabilities and quality of HyperLook.
34
35 Use Micropolis to showcase the unique ideas and features of Sugar, in an
36 exciting way that many people can easily understand.
37
38 CSound audio mixer.
39 Mesh networking.
40 D-bus messaging system.
41 Python scripting langauge.
42 GTK widgets.
43 Pie menus.
44 Communication and conferencing.
45 Chat, shared whiteboard, voting interface.
46 Learn to work together with other people, and argue your ideas.
47 Politics. Interpersonal communication and cooperation.
48 Immersive microworlds.
49 Inspire and teach kids to program.
50 Virtual datalogger, tricorder, lets you export and analyze logs and data from simulation.
51 Micropolis courseware.
52 Teach ecological and environmental issues.
53 Social studies.
54 Creative writing, developing language skills.
55 Science education.
56
57 ========================================================================
58
59 Notes on adapting Micropolis to the OLPC Sugar user interface:
60
61 Core Ideas:
62
63 Activities, not Applications
64
65 First cut:
66
67 Integrate the current TCL/Tk version of Micropolis to run as a simple activity within Sugar.
68
69 Restructure the multi-window TCL/Tk code to run in a single full screen window.
70 Implement a simple activity-oriented tiled window management interface.
71 Disable advanced features like multiple editor and map windows,
72 that require more sophisticated window management.
73 Instead of using a traditional multi-window management approach,
74
75 Make a simple wrapper around it that makes it appear in the Sugar user interface as an activity, like eToys does.
76
77 Long term:
78
79 Implement activity specific modes that reconfigure the user inteface (like Eclipse "perspectives").
80 - build/edit oriented interface
81 - query/analysis oriented interface
82 - financial oriented interface
83 - communication/coordination oriented interface
84 - dynamic zone finder analysis
85 - grid of several overall map views, each configured to show a different overlay.
86 - grid of several close-up map views, each centered on a different parts of the city (or tracking a player's cursor)
87
88 Collaboration: Enhance multi player mode to support sharing activities.
89 Both publishing your game for others to clone and play themselves (massively single player, like Spore),
90 and letting others join in your game (like the current cooperative multi-player mode)).
91 Multi player inte
92
93 Expression: Enhance chat, journaling, storytelling, and personalization aspects of the game.
94
95 Journaling: Record all events (both user edits and simulation events), chat messages and drawings.
96 Checkpoint the game state, and implement the ability to deterministically replay time stamped
97 editing events into the simulation, so you can fast forward and rewind from any checkpoint to
98 any step of the simulation.
99 Enable players to write newspaper articles about the cities, with live links to a snapshot
100 of the simulation and a place on the map, related to the story. Other players could browse
101 their published newspapers about the history of a city, and jump into that history at any time
102 from any story.
103
104 Iteration: Checkpoint game save files, allowing players to rewind history, and try "what-if" experiments.
105
106 Presence is Always Present
107
108 First cut:
109
110 Enhance the current X11 based multi player interface to support presence, the grid network, and messaging.
111 The current multi player interface runs a single Micropolis process on one laptop,
112 which connects to the local X server, and/or several other X servers on laptops over the net.
113 Rewrite the "Add User" dialog to be grid-network aware.
114 Instead of asking for an X server DISPLAY screen, provide a list of friends on the network.
115 Send an invitation to play to friends on the network.
116 Rewrite the built-in chat interface to integrate with the chat system used by Sugar.
117 Improve the shared "white board" overlay, so kids can draw on the map in different colors,
118 enable and disable different overlays, save overlays with the map, add text to overlays, etc.
119 Implement location based chat, by overlaying people icons and chat bubbles on the map.
120 Each player has a people icon "cursor" that they can move around the map (which follows
121 their selected editing cursor), and their chat messages show up in bubbles overlayed on the map.
122 When you select an editing tool, you can type what you're doing with the tool,
123 other people will be able to watch you, and make comments on what you're doing.
124
125 Long term:
126
127 Rewrite Micropolis in terms of Python/GTK/Cairo, and take full advantage of the Sugar libraries and services.
128 Support sharing, mentoring, colaboration, voting, political dialogs, journaling, etc.
129 Develop Micropolis into a exemplary, cutting edge demonstration of all that's great about Sugar.
130
131 Tools of Expression
132
133 Micropolis is great at supporting personal expression, interpretation and storytelling,
134 and leveraging what the player already knows to make connections to new knowledge,
135 and stimulating conversation, debate and analytical thinking.
136
137 Develop a web based "Wikipedia" oriented interface to Micropolis, supporting colaboration, discussion,
138 annotation, history journaling, and branching alternative histories.
139
140 Journaling
141
142 The "Micropolis Journal" could be realized as a web-based
143 newspaper-like interface.
144
145 Expose the multi player user interface through the web, instead of
146 using X11.
147
148 Automatically generate a newspaper for any particular time in a
149 city's history, from the simulator events and state, combined with
150 user written articles and chat messages.
151
152 The newspaper has sections that present automatically generated
153 snapshots of the information displayed in the various dialogs
154 (graph, evaluation, chat, notices, etc), and stories about
155 significant events (both user-generated and simulation-generated).
156
157 Enrich the city save file with metadata including the chat and
158 event journal, overlays, snapshots at different points in time (in
159 a branching "what-if" tree structure), etc.
160
161 In the Python version of Micropolis it will be easy to implement a
162 web server based interface that lets users read the city's
163 newspaper through the web browser, automatically inserting
164 pictures of the map corresponding to particular events in time. An
165 article about pollution going down could show a before and after
166 overall map with the polution overlay, and stuff like that.
167
168 Plug in modules to the simulator that analyze the state of the
169 city and generate events for the newspaper to write articles
170 about, including interesting stastical information and other
171 parameters to insert into the story template.
172
173 Implement "online surveys" that let newspaper readers vote on proposals
174 (expose the voting interface to web based users).
175
176 Use OpenLaszlo to develop a rich graphical AJAXian web service
177 based Micropolis interface, eliminating the need for the X11
178 interface, and enabling all kinds of interesting interface
179 customizations and mash-ups with other web services.
180
181 Know your Audience
182
183 Inexperienced
184
185 Keep the user interface simple, low surface area, direct, obvious, redundant, forgiving.
186 Gentle learning curve. Self revealing interface. Direct manipulation.
187 Integrated help and educational content.
188 Playback journals with voice-overs, so kids can learn by watching and listening to
189 recordings of teachers playing and describing what they're doing.
190 Multi player support for mentoring.
191
192 Young
193
194 Micropolis appeals to a wide range of age levels.
195
196 Design the user interface to support zooming, use large colorful
197 graphics, etc.
198
199 Do not require high coordination, fine pointer positioning, moving
200 the mouse while holding down the button, etc.
201
202 Scale across age levels by using interfaces that clearly reveal
203 themselves to novice users, but can be reconfigured by more
204 experienced users to be more streamlined.
205
206 For example, from the current interface: the map editor window has
207 a palette of editing tools, which makes it easy for novice users
208 to see and learn all the available editing commands, but consumes
209 precious screen space.
210
211 It also provides pie menus as a short cut to the palette, which
212 are layed out in the same arrangement as the palett (so the
213 palette serves as a map to the pie menus). Intermediate users can
214 use the palette as a map, to help learn the pie menus, and when
215 they are more experienced, they can close the palette to make the
216 map bigger, and use the pie menus exclusively.
217
218 The pie menus themselves are self-revealing, and have their own
219 gradual learning curve that supports graduation from inexperienced
220 users (click the menu up, look at the screen, move in the
221 direction, select the item), intermediate users (press down and
222 move in the direction, look at screen to make sure the right item
223 is selected, then select the item), and advanced users (mouse
224 ahead in the correct direction without looking at the screen).
225
226 International
227
228 The text in Micropolis needs to be broken out into external files so
229 it can be translated to different languages.
230
231 The Micropolis documentation, supporting essays about city planning,
232 and study guides need to be translated.
233
234 Best to do this after converting to Python/GTK/Cairo, since the
235 old version of TCL/Tk that Micropolis currently uses does not support
236 unicode or i18n.
237
238 Dig up the tile sets for different kinds of cities (old west,
239 european, futuristic, moon base, etc), develop new tile sets, and
240 enable children to easily develop their own tile sets and
241 interface skins.
242
243 Key Design Principles
244
245 Performance
246
247 Micropolis was designed to run well in a C64.
248
249 I've profiled and optimized it to run efficiently on Unix, and
250 take optimal advantage of the X11 window system.
251
252 Usability
253
254 Micropolis is fairly usable and approachable, but every effort should
255 be made to improve it, take maximum advantage of the Sugar user
256 interface, and for Micropolis to serve as a good example of Sugar
257 interface design, for others to emulate.
258
259 Simplicity
260
261 Some of the advanced features of the multi player X11 version of
262 Micropolis (like multiple map views and editors) will have to be
263 temporarily sidelined, and eventually reimplemented in simpler,
264 activity-oriented ways.
265
266 Reliability
267
268 Micropolis is currently pretty robust and can run for an indefinite
269 time without leaking memory or crashing.
270
271 The scripting language interface should try to protect against hard crashes,
272 but once you open it up to scripting, there are an infinite number of ways
273 programmers could make mistakes.
274
275 Security
276
277 The code should be audited for security.
278
279 User access to the scripting language and network remote control
280 code should be disabled.
281
282 Currently it allows any users to type TCL expressions, which is
283 great for cheating, but bad for security.
284
285 Currently there is some code in there to enable network remote
286 control (setting the tax rate and other parameters via a midi
287 slider box on a Mac running Bounce/Body Electric that sends UDP
288 packets to Micropolis when the user changes the slider). That should
289 be disabled (and eventually be replaced by a secure web service
290 based network interface.).
291
292 Adaptability
293
294 Adapt to different screen display modes and resolutions. Micropolis
295 has a high contrast monochrome tile set that it could use in
296 monochrome mode.
297
298 The color tiles look great in monochrome mode with gray scales,
299 but the high contrast monochrome tiles might be easier to see.
300
301 Need to support zooming into the map with any magnification, like
302 google maps (or the old PostScript-based HyperLook version of
303 Micropolis).
304
305 Support playing Micropolis with the game controller in book mode.
306
307 Instead of using X11 for multi player interaction (which will
308 cause the application to crash horribly if the network connection
309 is lost), reimplement the multi player mode on top of the dbus
310 messaging system, so it is more robust, and every player runs
311 their own instance of the simulator, so they all simulate together
312 in lock-step, like The Sims Online.
313
314 Recoverability
315
316 Use checkpointing and journaling to implement automatic back-up,
317 and expose a "rewind/fast forward" interface to the user, so they
318 can back up, change history, and replay changes at any point in time.
319
320 This is also the key to implementing a more advanced multi player
321 interface (better than the current X11 based system, more like The
322 Sims Online, where everyone runs their own copy of the simulation
323 in lock-step), so anyone can join the game by cloning its current
324 state, subscribing to its edit event stream, and submitting all
325 their edits to the master simulation (or going through the voting
326 negotiation system, like the current voting interface for building
327 expensive items and changing the tax rate).
328
329 Solve the colaborative undo/redo problem by allowing children to
330 branch out to their own private alternative histories. Instead of
331 overwriting the one main history, it inserts a branch point into
332 the shared history that links to their own private Idaho, which
333 itself may branch out into many histories. See Larry Niven's "All
334 the Myriad Ways".
335
336 Interoperability
337
338 Exposing Micropolis as a set of web services would enable all kinds
339 of interesting mash-ups and rich web based user interfaces.
340
341 Mobility
342
343 Support playing Micropolis in book mode with the game pad.
344
345 Transparency
346
347 The "view source" button could bring up the Micropolis source code.
348 Develop some source code documentation and extend the "How the
349 Simulator Works" documentation to link into the appropriate source
350 code. Annotate the C and Python source code to better explain how
351 it works.
352
353 Encourage children to learn Python programming (rather than
354 focusing on the C source code). Develop a robust Python scripting
355 interface that lets you hook into and control all aspects of the
356 simulator. Enable users to develop various kinds of Micropolis
357 plug-ins (buildings, editing tools, agents, disasters, etc) that
358 are easily scripted in Python, by subclassing.
359
360 Accessibility
361
362 Enable full keyboard control.
363 Enable full game pad control.
364 Enable full network control.
365 Speech synthesis and recorded voice feedback.
366 Zooming interface.
Impressum, Datenschutz