Design Team/Meetings
Who and what
The meeting is targeted to Sugar core and activity developers, but remains open to anyone interested. It's primary purpose is to open the design approach, making it more transparent and allowing the community to provide feedback on both current and upcoming features.
In general, discussion focuses on:
- high level design goals and ideas
- feedback and discussion of problems in the current design
- reviews of design proposals
When and where
- Biweekly, 1st and 3rd Thursdays
- 15.30 (UTC)
- irc.freenode.net, #sugar-meeting
To convert UTC to your local time, use this converter or run:
date -d '[current date] [time] UTC' date -d '2008-06-03 14:00 UTC'
Adding topics
You can add topics for discussion to the topics section for the meeting throughout the week. Posted topics will be collected and sent out in the announcement on the morning of the meeting.
Meetings
Thursday September 18, 2008 - 15.30 (UTC)
Topics
Visual Clipboard API
For reference, please see the clipboard specification. For a more targeted list of features and goals, please see the clipboard planning page.
We had a fairly long discussion about this, which didn't seem to get too far. Fortunately, a follow-up between Marco and I clarified some points, and we agreed that it should be possible to implement the majority of the goals across the system using the "formats" allowed in the GTK protocols, and falling back to sane defaults when extra info isn't provided.
Some references:
- http://www.pygtk.org/pygtk2tutorial/ch-NewInPyGTK2.2.html#sec-Clipboards
- http://www.pygtk.org/pygtk2tutorial/ch-DragAndDrop.html
- http://www.pygtk.org/pygtk2tutorial/ch-ManagingSelections.html
Advancing the Journal
I'd like to have a conversation regarding the current iteration of the Journal, future plans, and the steps we hope to take toward them in the next major release so we can scope our goals. The latest mockups (though slightly out of date) can be seen here.
Due to the lengthy clipboard discussion, we didn't hit this topic today. We'll pick it up first thing next week.
Icon reviews
We discussed three icons today.
Settings (control panel): By popular demand, a wrench was chosen as the base for this icon, though it was also proposed that a wrench and screwdriver could be clearer. It was agreed that the wrench is a simpler icon, and a more generic metaphor which could be used to represent "settings" throughout the system. A few visual tweaks (Trac #8198) made many happier with the wrench, but since this isn't a major change they can come post 8.2.
View Details (Journal): The old designs for this button closely resembled a play button (but with an open triangle, akin to a greater than (>) symbol), which some found confusing. The new proposal is an ellipsis [...] icon, to indicate the idea that more info is available, but omitted in the abbreviated list view. This works nicely within the [wiki.laptop.org/go/Designs/Journal new Journal designs], since the icons will occasionally appear within a string of icon-annotated text. All present agreed the latter was a better direction. This change could make 8.2.
Access Point: Recent experience reports have indicated that the removal of an identifier of the connected AP is frustrating. The proposal discussed is shown [1], which wraps the former AP icon (the circle) in "parenthesis" (meant to indicate radio signal). This retains the primitive circular shape of the current access points, but illustrates which is connected in a way which alludes to the wireless activity LED. The point was discussed that the other LED is actually more semantically correct, but not as suitable as an icon.
Additionally, these alternate designs were proposed, using antennae to make the purpose of the icons clearer. We may wish to elicit feedback about these alternatives from teachers and kids to see which convey the notion of wireless connectivity the best. The triangle proposed here was used once, and subsequently removed due to some distaste for the shape in this context, but it may still convey the idea better with the antenna. This change is strongly desired for 8.2.