Time |
Nick |
Message |
10:19 |
eben |
#topic highlights from previous roadmap discussion |
10:19 |
|
As I understand it, those who were around for the SugarCamp discussion on Saturday laid down a basic roadmap. |
10:20 |
tomeu |
that I was supposed to transcribe from the photos to the wiki |
10:20 |
eben |
I wasn't able to make that discussion, so in the interest of preventing redundant work, it would be great for someone to summarize that effort (perhaps it's already documented somewhere). |
10:20 |
dogi |
hi all :) |
10:21 |
tomeu |
I can write here what we wrote in the whiteboard |
10:21 |
|
hi dogi |
10:21 |
dogi |
:) |
10:21 |
tomeu |
ok to start with that? |
10:21 |
eben |
tomeu: Sounds good, you've got the floor. :) |
10:22 |
tomeu |
1. Legacy -> marcopg, (_bernie) |
10:22 |
|
2. Accessibility -> utoronto |
10:22 |
|
3. Stability |
10:22 |
|
4. Performance -> marcopg |
10:23 |
|
5. Portfolio/Journal -> scott, tomeu |
10:23 |
|
6. Bulletin board |
10:23 |
|
7. View source -> walter, tomeu |
10:23 |
|
8. Grab key |
10:23 |
marcopg |
I'm unlikely to be able to do 1 and 4 |
10:23 |
tomeu |
9. i18n |
10:24 |
marcopg |
unless olpc let me work on it |
10:24 |
tomeu |
10. Collaborate -> scott, marcopg |
10:24 |
|
11. Push to talk |
10:24 |
erikos |
what is 1? |
10:24 |
tomeu |
12. Base system |
10:25 |
|
13. Shared pointer session (VNC) |
10:25 |
|
14. File sharing via journal -> tomeu |
10:25 |
|
15. New collaboration features |
10:25 |
|
16. Work with distributors |
10:25 |
|
16. Work with distributors -> marcopg |
10:26 |
|
17. File passing fallback -> tomeu |
10:26 |
|
18. Overlay chat |
10:26 |
|
19. New activities |
10:26 |
|
20. Sugar apps in standard (legacy?) environments |
10:27 |
|
ok, so we do that, call it 0.84 and we can go home |
10:27 |
eben |
heh, excellent. |
10:28 |
morgs |
has to go, will be back later and read the log, especially interested in collaboration, distributors, overlay chat, file sharing, activities |
10:28 |
tomeu |
what doesn't have an owner is because the little green men will take care of that |
10:28 |
marcopg |
erikos: 1 is standard desktop applications |
10:29 |
tomeu |
17 is a very clever hack that someone thought of and that don't know why we didn't thought of before |
10:29 |
eben |
OK, so as this is a design meeting, I'm particularly interested in items which have implications in UI, and directly affect user experience. That reduces the scope, but only a little. |
10:29 |
erikos |
marcopg: ok |
10:29 |
eben |
So let's move through the list and discuss briefly each item which fits that description. Sound reasonable? |
10:29 |
tomeu |
17 means that if an activity doesn't support collaboration, we could transfer the journal entry first, then launch that activitiy on the other laptop |
10:30 |
erikos |
what is about the mesh view? |
10:30 |
walter |
Can I add a 21 which is a bit different in nature? |
10:30 |
|
21 Making UI adjustments for non-XO machnes |
10:30 |
erikos |
the UI to support the views that were added to telepathy? |
10:31 |
eben |
walter: interesting |
10:31 |
|
Does everyone agree with moving through the list? If so, I'll set the topic to each feature, and we can either toss it or discuss it briefly, and then move on. |
10:32 |
|
Unless, instead, owners of various topics have specific questions and would rather base the discussion around those instead... |
10:33 |
erikos |
eben: please go ahead |
10:34 |
eben |
#topic legacy |
10:34 |
|
It's not immediately clear how this affects UI, and that depends in part on how we go about it. |
10:34 |
tomeu |
I can take 21 |
10:34 |
eben |
marcopg: any comments on this? |
10:35 |
marcopg |
mmm |
10:35 |
|
I don't think it would affect UI |
10:35 |
|
other than the fact that it will be possible to have less integrated applications |
10:36 |
eben |
ok, I presume the primary goal here is running legacy apps in Sugar, right? |
10:36 |
|
We had some discussion already about how to handle non-sugar icons in our launcher, etc, but beyond that, we can breeze past this for now, I guess. |
10:36 |
marcopg |
yeah |
10:37 |
eben |
#topic accessibility |
10:37 |
marcopg |
running a parallel desktop is not a Sugar goal |
10:37 |
|
(but an olpc one) |
10:37 |
eben |
We don't have utoronto here at the moment |
10:37 |
|
Obviously accessibility and UI go hand in hand, but I think this can be handled on a case by case basis. |
10:38 |
|
Was there any discussion already about specific accessibility improvements? |
10:38 |
|
keyboard accessibility is a big one; Hippo has none right now. |
10:38 |
marcopg |
it seem to me that unless we have commitment to work on this, we won't be able to make it a goal |
10:38 |
eben |
We should put some effort into making accelerators ubiquitous in the OS and activities... |
10:39 |
icarito |
actually it would be very nice to fully keyboard navigate - i'm unable to do so, perhaps i miss some accelerators |
10:39 |
eben |
I think the accelerators is the best first order goal; and that's something that we need activity developers to assist with. |
10:40 |
|
icarito: Would you be willing to keep a list of instances where you find shortcuts missing? |
10:40 |
icarito |
eben ok i can take that responsibility |
10:40 |
tomeu |
accelerators++ |
10:40 |
icarito |
i'm using sugar more and more as my main desktop |
10:41 |
eben |
I believe we fixed a few problems with accelerators just before the 8.2 release. |
10:41 |
icarito |
i'll keep notes and share them about those |
10:41 |
eben |
So a call to activity developers to embrace them would also be wise. |
10:41 |
tomeu |
yup |
10:41 |
eben |
I think we can move on for now. |
10:41 |
|
#topic stability |
10:41 |
|
This is general, skipping it... |
10:42 |
|
performance is also general |
10:42 |
marcopg |
there might be some automatic testing work we can do |
10:42 |
eben |
#topic journal/portfolio |
10:42 |
marcopg |
and work with distro testing teams on processes |
10:42 |
|
but yeah very general |
10:42 |
eben |
This topic is quite large. Let's try to hit some key points without going into in depth discussion. |
10:42 |
|
I can see this going two ways: |
10:43 |
|
1. Scott has a fancy-pants new Journal concept. It's a prototype at the moment, and may or may not get done. |
10:43 |
|
2. Tomeu has a plugin replacement for the current backend, which improves things such as metadata support and stability. |
10:44 |
|
What I think we should discuss briefly are the features which we need regardless of which of these paths we choose. |
10:44 |
tomeu |
eben: I would also like to have some discussion about doable things that improve usability |
10:44 |
eben |
For instance... |
10:44 |
|
We don't have a way to filter to show only starred items in the list. |
10:44 |
tomeu |
sounds pretty good |
10:45 |
eben |
We need checkboxes to support multiple-selection and bulk operations such as deletion and tagging |
10:45 |
tomeu |
eben: I should assess how much work would take to implement the action/object view |
10:45 |
eben |
tomeu: That would be great. Honestly, I think there are a lot of things we can do to improve without introducing that split yet, but having a work estimate would be excellent. |
10:46 |
erikos |
eben: little things - like being able to launch an entry from the listview with any type matching activity |
10:46 |
tomeu |
ok |
10:46 |
eben |
Loosely related, we need to nail down what we mean by "encourage naming/tagging" and Just Do It (sorry, Nike) |
10:46 |
Gregorio |
on work estimate, it would really help a lot if we can track requirements and specifications |
10:46 |
eben |
erikos: Yes, that's another good one. |
10:47 |
icarito |
eben: actually, the UI could invite to rename the activity |
10:47 |
Gregorio |
I think all sugar roadmap items are cross referenced here: http://wiki.laptop.org/go/Feature_roadmap |
10:47 |
icarito |
a little affordance would be welcome |
10:47 |
erikos |
tomeu: and make it easy to download a file and access it from outside the journal |
10:47 |
icarito |
activities too often remain "activity x" on the journal |
10:47 |
Gregorio |
It doesn't matter much where you record it but please list the requirement and the design somewhere |
10:47 |
eben |
icarito: right, that's exactly why we want to start prompting more heavily; we just need to spec it and do it! |
10:48 |
walter |
I think the portfolio can live easily in these feature sets |
10:48 |
eben |
Does anyone else have any "small but important" improvements we should definitely push into the Journal for the next release? |
10:49 |
walter |
searching for starred items is key to me |
10:49 |
eben |
Another really big complaint in the field is that the Journal fills up, and people just wipe it. This is counter-productive to our educational goals. |
10:49 |
tomeu |
Gregorio: agreed, please keep pinging when we forget about it |
10:49 |
erikos |
eben: oh yeah this sounds bad |
10:49 |
eben |
Multiple-selection improves this some (since you can delete in batch)... |
10:49 |
|
But we might give some thought to a way for the Journal to /suggest/ items for deletion. |
10:50 |
|
This is not to say we should delete stuff willy-nilly, but beginning to introduce the idea of "forgetting", somehow, might be feasible. |
10:50 |
|
Do others think this is something worth some design cycles for this release? |
10:50 |
erikos |
eben: and maybe several levels of 'forgetting' |
10:50 |
tomeu |
yeah, well, as you said, we should start talking about doing things and Just Do It |
10:51 |
|
eben: that forgetting thing looks a bit fuzzy to me |
10:51 |
eben |
tomeu: how so? |
10:51 |
tomeu |
s/start/stop |
10:51 |
icarito |
perhaps older, unstarred items should be offered for deletion or backup? |
10:51 |
tomeu |
eben: I don't see how we could get to something implementable yet |
10:51 |
|
icarito: yeah, time and favoriteness are two criteria |
10:51 |
eben |
icarito: Right, there are a number of heuristics we can apply, such as un-starred, frequency of use, recency of use, etc. |
10:52 |
icarito |
just hates when systems think they are smart and creatively "suggest" wierd things |
10:52 |
|
but i guess its a tradeoff |
10:52 |
eben |
But ok. It sounds like most agree that, if we had a design, it would be worth a first pass. |
10:53 |
|
tomeu: you don't think we could reach something implementable? Or you don't think we have a design for something implementable? |
10:53 |
|
If you don't think we could find a design that is implementable, I may not give it more though; otherwise, I'd like to see how we could begin to introduce something in this area. |
10:54 |
|
Let's take it offline, I guess. I'll ponder it. Moving on? |
10:54 |
tomeu |
eben: I meant that we don't have a design |
10:54 |
|
and I don't see it as an easy problem |
10:55 |
icarito |
ok... recycle might be a nice metaphor btw instead of delete |
10:55 |
tomeu |
but there's no problem in discussing further |
10:55 |
erikos |
eben: lets see the 'able to group items' and delete them as a first start |
10:55 |
eben |
tomeu: OK. Then I'll work on one, keeping it simple ;) |
10:55 |
tomeu |
nice |
10:55 |
eben |
#topic bulletin board |
10:55 |
|
This has been an on-and-off topic since the beginning. |
10:55 |
|
I've actually thought a lot about this, and we discussed it at a previous design meeting to. |
10:56 |
marcopg |
but we don't have a solid design for it yet right? |
10:56 |
eben |
I'd like to table it, for now, because most recent thinking has indicated this might exist as an activity. |
10:56 |
|
And I don't think it's in the 9.1 timeframe, as it depends on a seamless inter-activity launching scheme. |
10:57 |
|
marcopg: I actually have fairly decent ideas around this. I will try to solidify some designs for it, but likely near the end of this cycle, perhaps for the next release instead. |
10:57 |
|
I don't think it's priority now. |
10:57 |
|
#topic view source |
10:58 |
|
I know Tomeu has worked some on this, and I believe a working prototype exists. |
10:58 |
|
Update there? |
10:58 |
tomeu |
need to address some feedback from activity authors |
10:58 |
|
some activities will need updating |
10:58 |
eben |
tomeu: could you outline the basic functionality? |
10:59 |
tomeu |
eben: it displays the content of the bundle on a tree view on the left |
10:59 |
|
and the source in the rest of the panel |
10:59 |
eben |
This is in a modal dialog (akin to control panel)? |
10:59 |
tomeu |
it can also show the source of a document if the activity provides it, like browse does |
10:59 |
|
eben: yup |
10:59 |
|
eben: you should just try it ;) |
10:59 |
eben |
tomeu: indeed |
11:00 |
erikos |
eben: room for design nitpicks - but a nice start ;p |
11:00 |
eben |
tomeu: OK. And right now, what's shown is chosen by the activity/system....that is, there is no option yet to the user if there are more than one possible things to show? |
11:00 |
tomeu |
eben: in the browse case, there's a button for switching between the bundle view and the document source |
11:01 |
|
eben: turtleart will be similar, some logo source will be displayed |
11:01 |
eben |
tomeu: Ah, neat. OK. So it sounds like I should indeed just try it, and it's mostly done apart from some design finesse. |
11:01 |
tomeu |
eben: in the etoys case, they will override all this and display instead the smalltalk code browser |
11:01 |
|
eben: yeah |
11:02 |
eben |
An idea I wanted to toss out quickly: The view source window /could/ also serve as a place for activity settings/prefs. |
11:02 |
|
Any comments on this? |
11:02 |
|
(Defining it more as a way to peek inside and/or tweak the behavior of an activity) |
11:03 |
erikos |
hmmm interesting |
11:03 |
eben |
Though we could also keep this wholly separate, and add a new icon to the activity toolbar (or menu) as well. |
11:03 |
tomeu |
yeah, it's interesting |
11:03 |
eben |
using the same icon used for the system. |
11:03 |
tomeu |
eben: was thinking of adding a menu item to the activity palette so the shortcut is more obvious |
11:03 |
eben |
I don't want to dwell on it now, actually, but we can go into more detail in a future design meeting. |
11:04 |
|
tomeu: Right, I would strongly suggest that as well, actually. |
11:04 |
|
OK, let's move on for now. |
11:04 |
erikos |
eben: i think the idea of 'pealing off layers' sounds right to me |
11:04 |
eben |
#topic grab key |
11:04 |
|
This is a thorn in my side. |
11:04 |
tomeu |
eben: but it's only available in olpc hardware |
11:04 |
erikos |
erikg has done some work on it, or? |
11:04 |
eben |
We /really/ need to make this work sooner than later, or we're going to have to abandon it altogether. |
11:05 |
tomeu |
eben: well, we need to think about non-olpc hw |
11:05 |
eben |
tomeu: well, is that strictly true? Another shortcut could be defined for non-olpc keyboards, right? |
11:05 |
icarito |
what would be an equivalent on non-xo hardware? |
11:05 |
tomeu |
icarito: there isn't a clear equivalent :/ |
11:05 |
|
icarito: closer would be the scrolling gesture in a multitouch touchpad |
11:05 |
erikos |
tomeu: this is a general issue we have to think about - people have difficulties to find the F1-F4 keys for the zoom levels |
11:05 |
eben |
tomeu: indeed.... |
11:06 |
|
That's exactly what we aim to mimic. |
11:06 |
marcopg |
grab key is not relevant to this meeting imo |
11:06 |
tomeu |
eben: well, we can add shortcuts to the zoom levels |
11:06 |
marcopg |
highly olpc specific |
11:06 |
eben |
erikos: That's solved by adding accelerators to those palettes |
11:06 |
tomeu |
right |
11:06 |
eben |
marcopg: Well, that's not entirely true. |
11:07 |
erikos |
eben: ok - cool - so i think this is a very important feature then - the accelerators |
11:07 |
eben |
If you claim that Sugar in general has no need for a grab key, then we should be discussing scrollbars instead. |
11:07 |
|
The current scrollbars are NOT designed for heavy conventional use. |
11:07 |
icarito |
perhaps we could use the windows key - affordance would be grabbing hand / greedy hand ;-) |
11:07 |
eben |
If, instead, we intend to depend on scrollbars in the conventional manner, we should be adjusting their design so they can be seen and grabbed more easily. |
11:08 |
icarito |
actually, I'd call scrollbars to attention as a priority if possible |
11:08 |
marcopg |
eben: well, on non-olpc hardware we will have to, right? |
11:08 |
icarito |
especially with current xo pointer |
11:08 |
marcopg |
unless you have ideas on doing somthing similar on generic hardware |
11:08 |
icarito |
scrolling is particularly bad on the xo |
11:08 |
eben |
marcopg: Well, that's what we need to figure out. |
11:09 |
|
Perhaps the solution in the short term, for everyone, is to increase the size of the scrollbar. How hard is such a change, to try it out? |
11:09 |
|
Is that a benzea question? |
11:10 |
marcopg |
very easy I think |
11:10 |
|
and yeah benzea can help |
11:10 |
icarito |
eben: i'd love it |
11:10 |
eben |
Or, would a shortcut such as ctrl-space (usually spacebar is used for this grabbing operation in applications) work as a system-wide scrolling modifier? |
11:11 |
marcopg |
eben: I'm a little unconvinced the button is a good solution on all hardware |
11:11 |
eben |
And, can we detect and/or make use of the multi-touch events for scrolling on hardware that supports it? |
11:11 |
marcopg |
if nothing else it will be useful on laptops where you can click and drag |
11:11 |
eben |
That would be ideal, honestly. |
11:11 |
marcopg |
s/useful/useless |
11:12 |
eben |
Perhaps someone in the community could look into making use of scrolling mechanisms on standard hardware... |
11:12 |
icarito |
eben: i agree with marcopg, its not a very conventional gesture, its fine, but bigger scrollbars i would love too |
11:12 |
marcopg |
eben: I guess I just see little interest by anyone to work on this feature :) |
11:12 |
eben |
do non-Mac laptops have gesture scrolling, or no? |
11:12 |
marcopg |
eben: they don't afaik |
11:12 |
eben |
hmm, ok. |
11:13 |
marcopg |
well mine doesn't :) |
11:13 |
eben |
So I'll think about adjusting scrollbar design, and I'll whine at OLPC about the grab key. |
11:13 |
|
next... |
11:13 |
|
#topic i18n |
11:13 |
|
Anything here for design? |
11:13 |
marcopg |
hopefully this can all be handled by olpc |
11:14 |
|
since it's in the deployability list |
11:14 |
eben |
ok |
11:14 |
marcopg |
(with help of the community obviously...) |
11:14 |
eben |
I'm going to skip collaboration since it's broad, and we also have a few points in teh list which identify specific features in that space... |
11:14 |
|
#topic push to talk |
11:14 |
marcopg |
only thing to say about general collab |
11:14 |
eben |
Can someone give a one or two sentence description of this idea? |
11:14 |
|
marcopg: sure |
11:14 |
marcopg |
is that it'd better work for the next release ;) |
11:14 |
eben |
marcopg: agreed! |
11:15 |
|
Thanks, everyone, for this discussion; hopefully we can wrap up in another 30 minutes or so. We're at an hour now since we began. |
11:16 |
|
So, push-to-talk? Anyone care to elaborate on the goal/plan? Or are we skipping it? |
11:16 |
|
It appears to have no owner at the moment. |
11:16 |
tomeu |
no idea |
11:16 |
|
it should be up for grabs |
11:16 |
walter |
grab key :) |
11:17 |
eben |
OK. Skipping until someone takes ownership, then. I'm not sure exactly how it's seen that this will integrate, but that can wait until someone aspires to do the work. |
11:17 |
|
#topic VNC/sared pointer |
11:17 |
|
This is a very interesting space, and I have given it some thought already. |
11:17 |
tomeu |
eben: you just need to invite scott for lunch |
11:18 |
eben |
It has no owner, but I'm happy to relate my thoughts if people are interested. |
11:18 |
marcopg |
is not particulary excited about that |
11:18 |
eben |
marcopg: don't find it useful? |
11:18 |
erikos |
has no clue what it means |
11:18 |
marcopg |
I'd rather focus on easy, rich collaboration for activities |
11:19 |
|
eben: might be useful, it just seem like a cheap solution which won't bring a lot of value though |
11:19 |
|
but hey |
11:19 |
|
I could be totally wrong :) |
11:19 |
|
anyway scott and cjb seem on it |
11:19 |
eben |
erikos: The general idea is that a) I can, for instance, select "View Simon's Screen" from the buddy menu, and then watch what you do. |
11:19 |
walter |
I think it is as much a market feature--expected by teachers |
11:19 |
|
but rarely used |
11:19 |
eben |
And b) It would be possible to select "View activity" from a shared activity menu to view just that activity session |
11:19 |
walter |
but on occasion useful |
11:20 |
marcopg |
walter: sure I can see it in that sense, I'd not try to sell it as collaboration though |
11:20 |
erikos |
eben: has this been requested from the field? |
11:20 |
walter |
but if it were implemented on a Sugar-like basis it could be useful |
11:20 |
eben |
Honestly, I think this could be a good answer in a number of situations, myself, but since a) few here are interested and b) there are interested parties who aren't here, we can skip it. |
11:20 |
walter |
small groups showing each other how they did something |
11:20 |
marcopg |
eben: sorry sorry |
11:20 |
|
eben: I didn't mean to stop you :) |
11:20 |
walter |
as opposed to the whole class following the leader |
11:20 |
eben |
erikos: Not in those words. But, for instance, teachers want to be able to guide kids through websites... |
11:21 |
marcopg |
the others might be interested |
11:21 |
|
just in bad mood today! |
11:21 |
eben |
Or be in charge of scrolling through a book, so everyone is at the right spot. |
11:21 |
walter |
In Chile, they did great work with this idea in groups fo four. |
11:21 |
eben |
It would also be useful for showing other kids how to do things....tutoring... |
11:21 |
erikos |
marcopg: go eat icecream then! |
11:21 |
|
eben: ok i see |
11:21 |
marcopg |
uff I went to Boston and didn't even eat my favorite ice cream |
11:22 |
|
all tomeu fault, he only wants to go to fucking pubs |
11:22 |
walter |
more of a tool for critique |
11:22 |
eben |
An idea I had for extending the idea, which I briefly mentioned to Scott, was that anyone in a screen session should be able to take screenshots at any time, which get stored as a slideshow in the Journal as a record... |
11:22 |
|
(Notice that I actually care less about the "shared pointer" idea....more about the ability to view someone's screen.) |
11:22 |
|
Anyway... |
11:22 |
erikos |
eben: i see it could be nice, but i *think* we have some areas that would need addressing first |
11:22 |
walter |
here is a scenario: |
11:22 |
caroline |
hi, sorry I'm late, is this the deployment meeting? |
11:23 |
marcopg |
caroline: ooops |
11:23 |
|
way late :) |
11:23 |
|
caroline: it finished 1 h ago or so |
11:23 |
walter |
teams of four work on a problem as individuals |
11:23 |
eben |
walter: sure, go ahead; we'll move on after your example. |
11:23 |
walter |
they then share their results among each other |
11:23 |
marcopg |
caroline: this meeting is interesting too though, design/roadmap :) |
11:23 |
walter |
they decide on one screen to share with the class. |
11:23 |
tomeu |
there's the desktop recording activity as well |
11:23 |
caroline |
ok thanks |
11:23 |
walter |
the teacher then chooses from the groups which screens to discuss with the whole class |
11:24 |
|
this is essentially the Chile model. |
11:24 |
eben |
Good use case. Another is the "watch a game" case... |
11:24 |
|
This comes for free if you can watch /any/ activity... |
11:24 |
walter |
it gets small discussions/debates going and then the teacher uses it to make a larger debate |
11:24 |
|
That is much different from all eyes forward or I am going to look over your shoulder |
11:25 |
eben |
shall we move on for now? |
11:25 |
tomeu |
move++ |
11:25 |
walter |
forward 100 |
11:25 |
|
right 90 |
11:25 |
eben |
#topic journal sharing |
11:26 |
|
This is something Scott has prototyped rather effectively, I think. |
11:26 |
|
tomeu: I see your name here, though. |
11:26 |
|
What's the plan here? |
11:26 |
tomeu |
eben: scott is doing pull, I'm doing push |
11:26 |
eben |
tomeu: I see, so this is push listed here. |
11:26 |
tomeu |
I guess |
11:26 |
eben |
I would prefer to call this "object transfer" then.... |
11:27 |
tomeu |
scott was there, so don't know why he didn't clarified |
11:27 |
eben |
It's not really sharing the Journal...it's a per-object way to send things to others. |
11:27 |
|
Oh oh... |
11:27 |
|
You do call it "file sharing" |
11:27 |
|
My mistake. |
11:27 |
|
OK, we already have designs for this posted on the wiki (currently laptop.org wiki, but that's another topic) |
11:28 |
|
So I think we can move right past this, unless you have any questions, tomeu. |
11:29 |
gregoriov |
sorry to interrupt, I got cut off but I'm back briefly with a question |
11:29 |
|
I think I saw someone working on NM interface |
11:29 |
eben |
erikos was, I think. |
11:29 |
marcopg |
gregoriov: yeah |
11:29 |
gregoriov |
thanks |
11:29 |
erikos |
gregoriov: yup i do |
11:29 |
tomeu |
eben: no questions for now |
11:30 |
eben |
#topic new collaboration features |
11:30 |
|
Anyone know what this means? |
11:30 |
|
It's unowned and, again, general |
11:30 |
walter |
we had a long list of new features for individual activities that suggested a few generalized featrues |
11:30 |
|
chat overlay, for example |
11:31 |
eben |
Chat overlay is also listed here as an OS feature. |
11:31 |
walter |
@tomeu: did that list get transcribed? |
11:31 |
eben |
We can skip over activity-specific features for the purpose of this discussion. |
11:31 |
|
But it would be good to see/publish that list. |
11:32 |
tomeu |
walter: http://sugarlabs.org/go/Sugarc[…]oadmap_brainstorm |
11:32 |
|
walter: oh, sorry |
11:32 |
walter |
I think we had consensus that a per activity chat overlay is important |
11:32 |
tomeu |
still need to transcribe it |
11:32 |
walter |
is that in the UI spec? |
11:32 |
tomeu |
not sure we can do most of what was in that list, though |
11:32 |
eben |
walter: overlay chat? We've done some preliminary designs. But let's get to that when we hit it in the list, in a moment. |
11:33 |
walter |
I think we want to publize the list to the community... |
11:33 |
eben |
#topic file passing fallback |
11:33 |
|
What does this mean? |
11:34 |
tomeu |
walter: agreed |
11:34 |
|
eben: I talked about |
11:34 |
|
eben: if an activity has no support for collaboration, fallback to transferring the journal entry and autolaunch the activity on the other machine |
11:34 |
eben |
tomeu: in what circumstance would that happen? |
11:35 |
tomeu |
eben: if I share one activity that has no sharing support, it would get advertised anyway |
11:35 |
eben |
tomeu: Oh....hmmm, I'm not sure that's a wise idea, actually. |
11:36 |
tomeu |
eben: when other user clicks on the icon, the entry would be transferred and resumed |
11:36 |
marcopg |
mmm |
11:36 |
eben |
That conflates two separate ideas with the same interaction...it won't be clear what to expect. |
11:36 |
|
Especialy since we plan on adding object transfer support this release. |
11:37 |
|
What I could see, however, is a separate "send to" button/menu item, which does as you describe... |
11:37 |
marcopg |
yeah not convinced about it either |
11:37 |
tomeu |
eben: what you say is not entirely stupid |
11:37 |
eben |
basically, a way to initiate an object transfer from the activity. |
11:37 |
marcopg |
haha |
11:37 |
tomeu |
oh, sounds good |
11:37 |
eben |
Also, what you're really getting at is a way to "share objects" in the neighborhood.... |
11:38 |
tomeu |
also solves the issue of unexpectedly autolaunching the activity when the transfer ends |
11:38 |
marcopg |
tomeu: just completely on crack, as usual |
11:38 |
tomeu |
marcopg: right :p |
11:38 |
eben |
This is something Christian and I both want to consider, but we think it has to be done carefully so that the distinction between shared activities and shared objects is clear. |
11:38 |
|
Let's not confuse the two yet. |
11:38 |
marcopg |
man these meetings are long |
11:38 |
|
we need mel to make us respect time ;) |
11:38 |
eben |
marcopg: sorry! almost done. |
11:39 |
marcopg |
eben: go go ;) |
11:39 |
eben |
OK, tomeu, you and I can discuss further later. |
11:39 |
|
#topic overlay chat. |
11:39 |
marcopg |
I would quite like that |
11:39 |
eben |
I agree that this is a highly requested, and highly valuable feature. |
11:39 |
|
Everyone wants it. |
11:39 |
marcopg |
esp since it's supposed to be easy |
11:39 |
|
also |
11:39 |
|
it was my idea :P |
11:39 |
eben |
I'll work through my preliminary designs for this soon, and add it to the adenga for our next design meeting (12/4) |
11:39 |
erikos |
didn't mister 'go' worked on it? |
11:39 |
eben |
sound good? |
11:39 |
marcopg |
(back in the days when eben didn't know about sugar) |
11:40 |
erikos |
eben: yes sounds good to me |
11:40 |
eben |
great |
11:40 |
|
if anyone wants to ping me in person with thoughts on this, feel free. |
11:40 |
tomeu |
eben: the proposal is to do something very simple, similar to the view source dialog |
11:40 |
eben |
Otherwise, we'll discuss on 12/4 |
11:40 |
tomeu |
eben: and have chat embedded there |
11:40 |
eben |
tomeu: OK. |
11:41 |
|
I can come up with parallel "ideal" and "short term proposal" sketches. |
11:41 |
tomeu |
not what was planned, but may be enough to get going |
11:41 |
eben |
sure |
11:41 |
|
#topic new activities. |
11:41 |
marcopg |
eben: don't even bother with the ideal :P |
11:41 |
eben |
I don't think we need to discuss this here. |
11:41 |
|
But if anyone has ideas for, or is working on, new activities and wants design input, ping me. |
11:42 |
|
OK. Sugar apps in legacy environments we can skip. |
11:42 |
marcopg |
thought we already discussed that |
11:42 |
eben |
#topic UI adjustments for non XO hardware |
11:42 |
marcopg |
ok |
11:42 |
|
walter: what are you thinking about there? |
11:42 |
eben |
marcopg: no, we discussed legacy apps in sugar environment....this is the other way around. |
11:42 |
|
anyway. |
11:42 |
marcopg |
clearly screen size |
11:42 |
tomeu |
eben: I got an eeepc I can use to work on that |
11:43 |
marcopg |
but also real UI changes? |
11:43 |
eben |
Yes, that's a big one....fixing the behavior of widgets etc. on larger screens would be good. |
11:43 |
tomeu |
eben: hope not so big |
11:43 |
icarito |
also i want to pitch an idea here |
11:43 |
eben |
Perhaps some conditional use of accelerators (F1-F4, for instance) |
11:43 |
tomeu |
marcopg: maybe some stuff in device icons and control panel? |
11:43 |
icarito |
i would very much like if it was possible to set a personalized background image and switch colors on non XO hardware |
11:44 |
eben |
The requested "logout" option might only apply to non XOs as well. |
11:44 |
tomeu |
yeah |
11:44 |
icarito |
perhaps contrast and brightness could be adjusted |
11:44 |
tomeu |
icarito: only on non-xo? |
11:44 |
icarito |
so as to not really interfere with usability |
11:44 |
erikos |
marcopg: we have to fix the font size as well |
11:44 |
marcopg |
tomeu: yeah |
11:44 |
icarito |
tomeu: on xo it makes sense because of the reflective screen |
11:44 |
marcopg |
just wondering if walter has something in mind other than the reported bugs |
11:44 |
|
but looks like he went back coding :) |
11:45 |
eben |
icarito: At the moment, I think I'm leaving the background request up to a hacker somewhere; though we'll consider personalization ideas moving forward with designs. |
11:45 |
icarito |
eben: i might work on this a little bit |
11:45 |
tomeu |
icarito: agreed |
11:46 |
icarito |
but cant promise anything |
11:46 |
|
i would love to offer a pretty sugar for computer labs |
11:46 |
|
eyecandy goes a long way |
11:46 |
eben |
icarito: You claim our Sugar isn't pretty as is? :( |
11:46 |
walter |
sorry I had to step away for a minute... |
11:47 |
icarito |
eben: its gorgeous - only a bit plain on regular monitors |
11:47 |
eben |
icarito: heh. |
11:47 |
walter |
I think there are some usability issues with the lack of a journal key and a frame key on non-XO systems |
11:47 |
icarito |
candy is made out of sugar |
11:47 |
walter |
CTRL-F is not very convenient |
11:47 |
eben |
walter: true |
11:47 |
|
do you have better sugestions? |
11:47 |
walter |
And I do not know the shortcut for the Journal |
11:47 |
marcopg |
eben: find solutions! |
11:48 |
eben |
Should we use more function keys? F12? |
11:48 |
|
(map it, positionally, to the XO keyboard) |
11:48 |
|
It's not any more discoverable, of course... |
11:48 |
walter |
I end up alt-tabbing to get to the Journal... |
11:48 |
|
I wish it were available in the cirlce |
11:48 |
|
the Frame--I use the corner a lot more. |
11:49 |
|
But there are some bugs that make it annoying. |
11:49 |
eben |
walter: You never use the Frame to reach the Journal? |
11:49 |
|
(I'm not sure why having it in Home would help, actually) |
11:49 |
walter |
Rarely--yet another step. |
11:49 |
marcopg |
walter: bugs? what is that? ;) |
11:49 |
eben |
Not "yet another"....just "a different" step. |
11:49 |
walter |
Lot of times I get a stack of hover menus when I call up the frame |
11:50 |
|
Eben: I disagree. |
11:50 |
marcopg |
walter: ticket please :) if you have a way to repro would be great |
11:50 |
erikos |
walter: we fixed this i think |
11:50 |
eben |
walter: how so? |
11:50 |
walter |
alt-tab is available on the keyboard. |
11:50 |
erikos |
walter: do you use latest sugar? |
11:50 |
eben |
Sure, so is the frame. |
11:50 |
walter |
the frame is too, but then I need to mouse over to the Journal |
11:50 |
marcopg |
eben: well the frame are two steps |
11:50 |
walter |
I am a bit behind in my jhbuild. |
11:50 |
marcopg |
1 go to corner 2 go to journal 3 click on it |
11:51 |
|
they are 3 actually |
11:51 |
eben |
Sure, short of a shortcut for the Journal itself, it's always at least 2 steps. |
11:51 |
|
That I can agree with. |
11:51 |
walter |
IMousing is harder for me than typing |
11:51 |
icarito |
+1 especiallly on xo hardware |
11:51 |
walter |
repeating the same step over and over is easy |
11:51 |
erikos |
walter: the bug i mean - is that palettes stay up in the left corner for some time and get stuck |
11:51 |
eben |
So perhaps we need to give more thought to accelerators, both on XO and on other hardware. |
11:51 |
walter |
erikos: yes |
11:51 |
marcopg |
yeah crappy touchpad doesn't help |
11:52 |
walter |
touchpad == crappy in my experience (on all hardware) |
11:52 |
eben |
Anything apart from efficiency of access to these common spaces? |
11:52 |
marcopg |
I'm happy with my thinkpad one but I'm sure it's very subjective |
11:52 |
walter |
No, but that is a big one. |
11:52 |
erikos |
walter: http://dev.laptop.org/git?p=su[…]00316f83c0374a085 |
11:52 |
marcopg |
the xo one is unsubjectively bad though ;) |
11:52 |
erikos |
walter: that was the fix for that |
11:52 |
walter |
(I disabled mine n the thinkpad--just used the stick) |
11:53 |
|
erikos: I will try it. |
11:53 |
eben |
OK, it looks like we can wrap up, then. |
11:53 |
erikos |
walter: great - otherwise please file at d.s.o :) |
11:53 |
eben |
Any closing comments? |
11:53 |
marcopg |
nice meeting! |
11:53 |
|
thanks! |
11:53 |
walter |
Sugar rocks!! |
11:53 |
erikos |
eben: i have a few design issues in my NM work |
11:53 |
tomeu |
party! |
11:53 |
erikos |
eben: but those we can discus offline |
11:53 |
eben |
Thanks everyone for participating! |
11:53 |
marcopg |
Sugar people rocks!! |
11:54 |
eben |
erikos: ok, we can chat after the meeting. |
11:54 |
erikos |
eben: yup yup |
11:54 |
eben |
We'll have our next meting right here on December 4th. |
11:54 |
erikos |
eben: where was christian? |
11:54 |
marcopg |
eben: you need to stop the bot btw |
11:54 |
|
bad christian yeah |
11:54 |
|
and no t-shirts yet! |
11:54 |
eben |
erikos: He thought it was tomorrow. |
11:54 |
marcopg |
eeek |
11:54 |
eben |
I'll point him to logs... |
11:54 |
|
incidentally, where are the logs found? |
11:55 |
erikos |
the bot does tell you |
11:55 |
marcopg |
meeting.sugarlabs.org |
11:55 |
|
despite what the bot tells you |
11:55 |
erikos |
the bot does tell you! |
11:55 |
eben |
#endmeeting |