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 -community) are able to determine, a feature was removed by the process of someone @openmoko saying "I don't like that" and emailing Raster (or IRCing him or walking into his office) and saying "pull that" without saying to the users "hey, before we do this, are you using that feature? do *you* think it's ugly or confusing?" Openmoko has always promoted itself as "fully open" - to quote Michael's words a couple of days ago: the goal of the project is not to create a new cellphone, but rather, that by being open, we allow and encourage innovation, and that by working with you, the open source community, we tap into a huge pool of imaginative, creative, very smart and hardworking innovators. I have always understood Openmoko's openness to encompass the *entire breadth* of Openmoko software development. It's great if we can write apps for the Freerunner, but I can already write apps for Symbian or Windows Mobile. It's great that I can fork the code Openmoko are writing commercially and make modifications to the application manager or the dialler but that's obviously a duplication of effort - I thought you wanted the community to help contribute to the core applications, too. Isn't this the case? Let's talk about the hypothetical community member Bob. Bob has a great idea a feature that he'd like to see on his mobile phone. Let's say he's meeting Charlie at cafe near the Linux convention and he thinks "it'd be great if I could select Charlie in my phone's addressbook and - alongside 'call contact' and 'SMS contact' - it said 'Send my location'. I'd just click that and it could SMS my GPS location to Charlie and on Charlie's phone it would pop up a message 'Bob has sent you his location by SMS. Would you like to see where he is?' and then show a map with my location on it (or at least a needle showing distance and direction)". Under a normal community development process Bob has some idea of whether or not other developers might like this idea. He can message them on IRC and say "would you include that in the main tree?" Bob can hack together a bit of code showing a working prototype and post patches to the mailing list knowing that the community will at least consider it. They might say "cool idea, but no-one'll use it, so we don't want it in the core distro", they might say "it needs a lot of polish", they might say "add a configuration option to enable/disable it". But even if they ultimately reject it, Bob can submit his code with some idea of the shared goals of the other developers and knowing that the idea will be considered on the merits of whether the other developers think it's cool or not. I guess my assumption was that this was development process for Openmoko & ASU. There's a difference between goals of "the simplest mobile phone stack" and "the most configurable mobile phone stack" and "the coolest mobile phone stack", but basically I assumed that one could contribute to core apps and submissions would be considered by what the existing developers thought of the idea and the code. It's a bit of work to implement Bob's idea. The contacts application has to be patched, as does the code which receives & displays SMS messages. You have to get the location from the GPS and you have to interface with existing map software or write your own program for showing location / destination. The implication of the "designers decided that ASU is not to have any manual keyboard toggle button" is that one can undertake all the work for getting something like this prototyped and it'll be rejected out- of-hand by someone at Openmoko. And from Raster's reluctance to say who over-ruled him on the keyboard thing, one might not know who! There's no-one to appeal to! As I said before, even worse is the idea that the developers might think the idea is great and that it gets accepted and Bob does more work polishing and refining his idea, then it shows up in a daily build and someone at Openmoko notices enough to have it removed. So the big question - assuming you DO want volunteer contributions to the core software stack - is "how do I know if my idea is worth pursuing?" There's apparently no design document saying where ASU (or whatever) is going in terms of features. We don't know who to contact in order to get approval for our concepts before we waste a lot of time on them. A developer probably doesn't want to go through some long pre- implementation approvals process before starting work - he doesn't want to create GUI mock-ups and write a long design-rationale proposal document (he just wants to dive into some code) but at least that way there'd be _some_ kind of process to go through. I guess at some point this raises the goal of the Openmoko software stack. "Encouraging innovation" and "leveraging the synergies of our creative community" are just buzzwords when it comes to the final implementation details - I guess the whole point of Openmoko is to evolve into a software stack that you can install on your phones in order to sell more of your hardware, but should we be coding features suitable for little old ladies? Or should we be coding features aimed at typical Ubuntu users? Features to lure customers from Windows Mobile or Blackberry? As I said, I always assumed that features would be included if the community in general liked them, but right now I can't imagine anyone who can configure wifi and bluetooth being confused by a button to trigger an on-screen keyboard (such a button having been present in Windows Mobile 3 years ago), so I just can't make sense of this. I started writing this message hoping to pose a handful of concise questions, but clearly I like the sound of my own typing too much for that. I'm sorry I'm so verbose, but I hope you can see the context of my concerns. Stroller. _______________________________________________ Openmoko community mailing list email@example.com http://lists.openmoko.org/mailman/listinfo/community