Re: Community contributions to core apps features. (Was: Terminal forASU)
Stroller, Please try to see the bigger picture. The questions you are posing have nothing to do with design, and everything to do with emotions. You see something you don't like, you want to understand why it was implemented, and how to change it. Its the same emotions that ignited Sean to start this project. It almost doesn't matter if we are an open project or not. Anyone with a fair amount of googling skills can hack phones. ASU's inititative, since day one, was to gather information from the internet and pipe it to the phone in an easy and accessable way. ASU is not in any way about design. Its about organization. By removing a feature, we are forced to self-organize using the resources within our environment. On the net, we would share ideas through the wiki, projects and mailing lists. We hope to see this same type of sharing within the phone, using resources like installer (aka assassin). If you do not like a certain feature, please change it, document it and share it. I find these discussions ignited by Raster, highly contradicting, especially when he was the one defending the 'why should om support only one toolkit' discussions from a month ago. Now, all of the sudden, we should support one distribution, that happens to include a qwerty button. ASU was designed to be empty, supporting various ideas, toolkits, skins, keyboards, you name it. Getting into discussions about 'design decisions' is so entirely narrow that we are missing the point. Everyone should fork. Everyone should create their own distribution, we only ask that this is done responsibily, by documenting it in a way where the benefits of your customizations can be shared by others. Our jobs as designers was to think about how to organize this information within an ever evolving system, using the very resources available to us. I can't say that we have succeeded in any way, we are still taking the first steps (actually we haven't even taken the first step, ASU isn't even officially released yet!). I read every single mail on this list. I believe in replying in a way that answers questions, not in a way that feeds to emotions, for the very reason that emotions can not be argued with. I will also do my best to answer questions to be more transparent about our group, but please have some mercy! We do work full time, and it is hard to keep up sometimes ;) Regards, Will -Original Message- From: Stroller [EMAIL PROTECTED] Date: Sat, 26 Jul 2008 08:46:55 To: List for Openmoko community discussioncommunity@lists.openmoko.org Cc: steve[EMAIL PROTECTED] Subject: Community contributions to core apps features. (Was: Terminal for ASU) On 26 Jul 2008, at 03:10, steve wrote: Ask your questions stroller. I'll do my best to answer them. Hi Steve, Thanks for your reply. I've posted my questions - or rather a request for openness clarification - already in this thread. Because the background of the thread already contains all context you ought to need, it's difficult to know where to start asking you questions. Let me try. On 21 Jul 2008, at 19:47, Carsten Haitzler (The Rasterman) wrote: the problem is the designers decided that ASU is not to have any manual keyboard toggle button because it will disturb the design and/or confuse users, so all apps and toolkits need modification to talk a protocol to bring up the keyboard on demand (no manual controls). that is why you need to do this. personally i think you need a manual control because, as such, many apps and toolkits will not be changed, or they will get it wrong and give you a keyboard when you don't want one, or decide not to give you one when you do... but that's not my call. - Who are the designers who decided that ASU is not to have any manual keyboard toggle button because it will disturb the design and/ or confuse users please? Was this a group of Openmoko employees? Or a single individual at Openmoko? Does this person have a specified role managing the design of ASU? Who do users bitch to if they don't like design decisions? - How do you respond to Raster's suggestion that a manual override will be needed? - Is a complicated protocol to bring up the keyboard on demand - which each input method will need to be patched to support - *really* better than a simple button? - Will it be difficult to accommodate this protocol when porting an input method (Dasher, for instance) to Openmoko? Or will it be simple enough to do so that it easily justifies that lack of a manual keyboard button? No. Ignore those questions. This is only a small thing. I haven't followed the details of the problem closely - it was Raster's i wanted to do this this way, but i wasn't allowed to that surprised me - but it looks like the problems that this introduces aren't unmanageable. What is of more concern is the connotations of this decision. As far as we (end-users on
Re: Community contributions to core apps features. (Was: Terminal forASU)
On Sat, 26 Jul 2008 11:44:21 + [EMAIL PROTECTED] babbled: Stroller, Please try to see the bigger picture. The questions you are posing have nothing to do with design, and everything to do with emotions. You see something you don't like, you want to understand why it was implemented, and how to change it. Its the same emotions that ignited Sean to start this project. It almost doesn't matter if we are an open project or not. Anyone with a fair amount of googling skills can hack phones. ASU's inititative, since day one, was to gather information from the internet and pipe it to the phone in an easy and accessable way. ASU is not in any way about design. Its about organization. By removing a feature, we are forced to self-organize using the resources within our environment. On the net, we would share ideas that is not the point. the point is that TEHCNICALLY many apps wont work without a manual keyboard control - they need lots of modifying. the fact is users DEMAND the control. automatic isn't reliable - and likely will never be given a heterogeneous software environment. if you are apple and all applications are your sand your write everything - you can guarantee everything behaves one way. we are not apple. hell we don't have even a fraction o the core systems or protocols or libraries etc. in place. we are in no position currently - on s technical level, to pretend to do this. through the wiki, projects and mailing lists. We hope to see this same type of sharing within the phone, using resources like installer (aka assassin). If you do not like a certain feature, please change it, document it and share it. I find these discussions ignited by Raster, highly contradicting, especially when he was the one defending the 'why should om support only one toolkit' discussions from a month ago. Now, all of the sudden, we should support one distribution, that happens to include a qwerty button. ASU was never said - that. i said already i intend to fork off my own distribution. for me ASU is not usable. the people here said i don't want to fork - i want to contribute to the core OS that openmoko supports and distributes. the way asu is done requires forks. there is no contribution mechaism tat may in any way affect design. multiple toolkits is a specious argument in this case. they can all live together at the same time. on the same distribution and on the same windowing system (well qtopia ported to x11 can. normal qtopia(on qws) cannot... well.. that can be argued (implement a vfb in a window...)). the existence and working of multiple toolkits is orthogonal to design and forking. users were asking for something. a feature they need/want. they'd like it out of the box. they will not get it. it is not in the design. i cannot answer for that. i can't change the design. they will need to do their own fork that is a replacement package(set) to start enabling lots of features. it starts with theme. like 2007.2 vs qtopia vs. FSO vs ASU pretty much, just a smaller scale. there is a VAST difference of having multiple toolkits available together under 1 distribution and 1 ui core (x11), vs design decisions to remove features (the keyboard button is a trivial one - as it can be brought back with a theme change) but there are many other that once they are removed require massive efforts to bring back (code changes, config changes that cannot be done as the only way to do them is via guis' that have been disabled, so you need to do temporary code hacks to force them back to lie and back to being accessible so you can modify the config). for example - you now need to fork illume and make your own illume packages. that also requires a cleanout of the user config if they used it before. users dont WANT to do this. but that is what you (and sean) want them to do. multiple toolkits vs, forking packages... these are very different issues. designed to be empty, supporting various ideas, toolkits, skins, keyboards, you name it. Getting into discussions about 'design decisions' is so entirely narrow that we are missing the point. Everyone should fork. THIS is the problem. and i have been repremanded by sean for saying just this - that you and sean said that everyone should fork, to me - do their own thing. people asked if they need to do this, they fear needing to do it as it fragment effort and they cant help the core system as they hoped to - and i said that they need to. they need to do their own thing. i am just the messenger. i ignited nothing - i simply said what was the facts in this case. i have chosen my words carefully and have remained factual and neutral. i have personal opinions on elements of design choice - based on technical arguments, but that is as far as they can go in ASU. i am not able to make design changes. it's not my call - i have been firmly informed of the unhappiness of me doing anything in addition or differently to or other than instructed to in the design. i thus
