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.