Re: Openmoko on Design
I have a MIDI keyboard I can bring with me to LinuxWorld, and a USB/MIDI interface. If your synth is ready in time I'd love to show it. M Jay Vaughan wrote: 7) Maybe run some simple synth applications on the FR, using the USB host mode to connect it to a MIDI keyboard. this is what i'm doing this weekend .. ;) ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
I have a MIDI keyboard I can bring with me to LinuxWorld, and a USB/ MIDI interface. Well I spent some time hacking on it this weekend and I've gotten a basic MIDI parser/librarian/sequencer setup on the Freerunner now .. great fun to play back tracks to my 19 rack using the Freerunner! But I've got some cleaning up to do and some serious catching up to do in the packaging department before I can put this out there for general use - right now its quite a bit hacky to get things started. If your synth is ready in time I'd love to show it. M It would be nice indeed, but I don't think I'm ready to release yet .. I have to get move away from my current hacked-up configuration to a cleaner, public-packaged style setup .. and I can't really do that with the moving targets of our current images, alas .. but stay tuned, because if things go well with this weeks new ASU release, I'll do my work all over again and make sure I produce proper packages that will work for a majority. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Jay Vaughan wrote: I have a MIDI keyboard I can bring with me to LinuxWorld, and a USB/ MIDI interface. Well I spent some time hacking on it this weekend and I've gotten a basic MIDI parser/librarian/sequencer setup on the Freerunner now .. great fun to play back tracks to my 19 rack using the Freerunner! But I've got some cleaning up to do and some serious catching up to do in the packaging department before I can put this out there for general use - right now its quite a bit hacky to get things started. If your synth is ready in time I'd love to show it. M It would be nice indeed, but I don't think I'm ready to release yet .. I have to get move away from my current hacked-up configuration to a cleaner, public-packaged style setup .. and I can't really do that with the moving targets of our current images, alas .. but stay tuned, because if things go well with this weeks new ASU release, I'll do my work all over again and make sure I produce proper packages that will work for a majority. No worries - there will be plenty of other opportunities. I am no musician myself but have plenty of friends who are, and are Linux geeks as well, and they will love this. Please keep us informed. Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Wed, Jul 30, 2008 at 11:38:07AM +0800, John Lee wrote: On Wed, Jul 30, 2008 at 01:47:29AM +0100, Al Johnson wrote: I'll snip most of it to keep the length reasonable. same here :) On Tuesday 29 July 2008, William Lai wrote: It already is. We've offered a couple of different solutions to community requests that were declined by, well, engineering. One of them was: * create a package to be installed through installer adding manual qwerty button to illume theme. The only suggestion I remember was that the community fork illume. Is this a different take on the same suggestion, or a different suggestion? What was the other option? And what was the objection to providing it as a configuration option with the default being off, as proposed on this list? What we are trying to do: provide a OM repository and a community repository. in this particular case, if in the end the illume still shipped without kbd button, then the community will very likely provide another version of illume called illume-kbd in the community repository. thus you can replace the shipped illume with illume-kbd, and the next upgrade will get the new version of illume-kbd instead of illume, so you don't need to change it again after upgrade. Where we are right at the moment: illume is there. the community repository is not ready yet but we're working on it. the dependency handling of replacing the shipped illume with illume-kbd is not ready yet but we're working on it. My personal comment on this: if the illume is so much more popular then illume-kdb (theoretically we can know that from the repository log) or the other way around then you bet that fact will be very effective in OM. ;) I bought the FreeRunner in order to: 1) Use for remote system administration, via a terminal and onscreen keyboards, via SSH over WiFi and GPRS. 2) Browse the web via WiFi and/or GPRS 3) Read/write email using some kind of IMAP mail app, and send/recieve SMS 4) Make and receive calls via VOIP and GSM 5) Play media (Vorbis, MP3, FLV's, MP4's) and record audio 6) Write a custom touchscreen UI app for a linux-based music synthesizer (connecting to the synth via Bluetooth) 7) Maybe run some simple synth applications on the FR, using the USB host mode to connect it to a MIDI keyboard. So far, not even the first 5 of those are complete and reliable enough for me to actually use without hassle, and based on what I've read here, I'm estimating about 2 years before they are. In the meantime, however, I've realized that I can probably get through the rest of my life happily without *any* of the above features, and I should have waited a few more years before spending so much money. -ken ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Thu, Jul 31, 2008 at 4:27 AM, Ken Restivo [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2008 at 11:38:07AM +0800, John Lee wrote: On Wed, Jul 30, 2008 at 01:47:29AM +0100, Al Johnson wrote: I'll snip most of it to keep the length reasonable. same here :) On Tuesday 29 July 2008, William Lai wrote: It already is. We've offered a couple of different solutions to community requests that were declined by, well, engineering. One of them was: * create a package to be installed through installer adding manual qwerty button to illume theme. The only suggestion I remember was that the community fork illume. Is this a different take on the same suggestion, or a different suggestion? What was the other option? And what was the objection to providing it as a configuration option with the default being off, as proposed on this list? What we are trying to do: provide a OM repository and a community repository. in this particular case, if in the end the illume still shipped without kbd button, then the community will very likely provide another version of illume called illume-kbd in the community repository. thus you can replace the shipped illume with illume-kbd, and the next upgrade will get the new version of illume-kbd instead of illume, so you don't need to change it again after upgrade. Where we are right at the moment: illume is there. the community repository is not ready yet but we're working on it. the dependency handling of replacing the shipped illume with illume-kbd is not ready yet but we're working on it. My personal comment on this: if the illume is so much more popular then illume-kdb (theoretically we can know that from the repository log) or the other way around then you bet that fact will be very effective in OM. ;) I bought the FreeRunner in order to: 1) Use for remote system administration, via a terminal and onscreen keyboards, via SSH over WiFi and GPRS. 2) Browse the web via WiFi and/or GPRS 3) Read/write email using some kind of IMAP mail app, and send/recieve SMS 4) Make and receive calls via VOIP and GSM 5) Play media (Vorbis, MP3, FLV's, MP4's) and record audio 6) Write a custom touchscreen UI app for a linux-based music synthesizer (connecting to the synth via Bluetooth) 7) Maybe run some simple synth applications on the FR, using the USB host mode to connect it to a MIDI keyboard. So far, not even the first 5 of those are complete and reliable enough for me to actually use without hassle, and based on what I've read here, I'm estimating about 2 years before they are. 2 years? At the rate I am seeing progress, I would bet closer to two months, as it seems the ASU and eventual FSO images are coming along quite nicely. In the meantime, however, I've realized that I can probably get through the rest of my life happily without *any* of the above features, and I should have waited a few more years before spending so much money. -ken ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
7) Maybe run some simple synth applications on the FR, using the USB host mode to connect it to a MIDI keyboard. this is what i'm doing this weekend .. ;) ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Wed, Jul 30, 2008 at 11:28:13AM +0800, Marek Lindner wrote: On Wednesday, 30. July 2008 10:18:33 Al Johnson wrote: I agree with everything you say here. The keyboard should just appear when I want it and disappear when I don't. The absence of a manual override means that whenever it gets it wrong I can't correct it, the worst case being when I need to enter something but the keyboard doesn't appear. Conversely the presence of a manual override causes no problem even if it is never needed. The keyboard failing to appear is not a hypothetical scenario. Without manual intervention minimo was unusable because the keyboard didn't appear when the cursor was placed for URL entry. This is likely to be an issue with other apps that don't have a specific openmoko port, and we shouldn't have to create such a port just to use an otherwise capable app on openmoko. Other issues include the keyboard appearing when an edit field has focus although I don't want to edit it, keyboard appearing and disappearing frequently if a form contains mixed input types, or appearing over the top of the field to be edited. The field having focus although editing is not required is probably impossible to detect because the answer depends on the opinion of the user at the time. I understand your points and they all are valid. How do we address them ? That brings us back to Seans mail. Openmoko will provide the minimum set of applications and basic functionality that empowers ordinary users to use the phone. We will make sure that these applications work well with the environment we provide. This is an ongoing process we just started compared to many established phone systems. Feel invited to extend that basic system through packages that can be installed. If you install an application that hasn't been ported to the Openmoko platform and does not support the keyboard you also should install the manual keyboard button or you just install a package which deativates the automatic keyboard behaviour right away if you don't like it. We have to realize that the world is very diverse - we wont find a solution which suits for everybody in all the cases. So, we have to make it flexible. Again: This is a process and you can help us with that. I feel terrible about this whole mess because I was one of the first people in the original terminal thread, and I filed one of the original bug reports on it too. I don't expect to be able to stop the mailing-list train wreck from continuing, now that it has developed a momentum of its own, except to apologize for having been involved in starting it in the first place. Sorry about that. -ken ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 7/30/08 Daniel Benoy wrote: Also, would the openmoko design team be willing to consider a toggle in the configuration menu between manual and automatic? What we want is for people to add their own configuration options to menus in the form of packages installable from the Installer. This is why we remove functionality. So we can focus on how to make sure our products are extensible. Simplify and Open. -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
If you go read Morse Peckham's book http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/080520142 You will understand how museuems and gallery's function; and, Sean's words will strike you more deeply. Its all well and good when you're dealing with art students, but when you hope to sell 1,000 Freerunners as the base hardware platform for a multinational operation, it doesn't sell too well. Sorry. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 7/30/08 Jay Vaughan wrote: If you go read Morse Peckham's book http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/080520142 You will understand how museuems and gallery's function; and, Sean's words will strike you more deeply. Its all well and good when you're dealing with art students, but when you hope to sell 1,000 Freerunners as the base hardware platform for a multinational operation, it doesn't sell too well. Yes Jay. That is exactly the goal of this company. Sell 1,000 phones. They we all can retire. -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 7/30/08 Jay Vaughan wrote: If you go read Morse Peckham's book http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/080520142 You will understand how museuems and gallery's function; and, Sean's words will strike you more deeply. Its all well and good when you're dealing with art students, but when you hope to sell 1,000 Freerunners as the base hardware platform for a multinational operation, it doesn't sell too well. Yes Jay. That is exactly the goal of this company. Sell 1,000 phones. They we all can retire. Come on now. If OM can only respond with hostile ad hominems to IMHO valid critisism, then I fear for the life of this 'community'. Without solid leadership this community will fragment (which, to some degree, it already has) and lose momentum. And that is hard to regain. And to stay with the museum/gallery metaphor; If you don't use high quality paint and canvas, it'll all fade away quickly. Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Yes Jay. That is exactly the goal of this company. Sell 1,000 phones. They we all can retire. -Sean wtf? you're ridiculing a single order of 1,000 phones being placed at one time by an enthusiastic customer? sheesh. what sort of CEO are you? *all* orders, large and small, are worth the effort, or is that not true? i suggest you think about this a little. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Yes Jay. That is exactly the goal of this company. Sell 1,000 phones. They we all can retire. wtf? you're ridiculing a single order of 1,000 phones being placed at one time by an enthusiastic customer? sheesh. what sort of CEO are you? chill. only a misunderstanding probably -- you were talking about a single order of 1.000 phones, sean was obviously understanding an overall sale of 1.000 phones (and so did i). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 7/30/08 Jay Vaughan wrote: Yes Jay. That is exactly the goal of this company. Sell 1,000 phones. They we all can retire. -Sean wtf? you're ridiculing a single order of 1,000 phones being placed at one time by an enthusiastic customer? sheesh. what sort of CEO are you? *all* orders, large and small, are worth the effort, or is that not true? i suggest you think about this a little. Jay, give me a break. It was a joke. You chide me for selling to art students. Can't I poke a bit of fun, too? ;-) No hard feelings man. Seriously. Let's all get on with our day. -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 7/30/08 arne anka wrote: Yes Jay. That is exactly the goal of this company. Sell 1,000 phones. They we all can retire. wtf? you're ridiculing a single order of 1,000 phones being placed at one time by an enthusiastic customer? sheesh. what sort of CEO are you? chill. only a misunderstanding probably -- you were talking about a single order of 1.000 phones, sean was obviously understanding an overall sale of 1.000 phones (and so did i). Yeah it was a misunderstanding then. That's exactly what I was referring to. Too many emails :-) Only a joke Jay. Nothing personal. -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Yeah it was a misunderstanding then. That's exactly what I was referring to. Too many emails :-) Only a joke Jay. Nothing personal. okay, so please consider this .. i have a customer with the potential to place an order for 1,000 phones. when do you propose i go to them and close the deal? ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openmoko on Design
Actually Jay, The book is about behavior and biology and how we perceive things. But let's not argue. Let's solve your problem.. How can I help? Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jay Vaughan Sent: Wednesday, July 30, 2008 1:21 AM To: List for Openmoko community discussion Cc: [EMAIL PROTECTED] Subject: Re: Openmoko on Design If you go read Morse Peckham's book http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/080520142 You will understand how museuems and gallery's function; and, Sean's words will strike you more deeply. Its all well and good when you're dealing with art students, but when you hope to sell 1,000 Freerunners as the base hardware platform for a multinational operation, it doesn't sell too well. Sorry. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Sean Moss-Pultz wrote: On 7/30/08 Daniel Benoy wrote: Also, would the openmoko design team be willing to consider a toggle in the configuration menu between manual and automatic? What we want is for people to add their own configuration options to menus in the form of packages installable from the Installer. This is why we remove functionality. So we can focus on how to make sure our products are extensible. This seems like a bullshit answer to me. Taking functionality away doesn't improve the FR. It makes it less useful. Are you guys deaf or something? Haven't you hear the screams from the people who plonked down their cold hard cash for your product about this reduction in functionality? Or are you just so damn arrogant you think its your way or the highway? If the functionality was there and you felt it should be an option, YOU should have made it one! But thats not what you did. You made it difficult for a programmer to temporarily bring it back, and no way to make it a user selectable option. bah!! Scott signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Scott wrote: Sean Moss-Pultz wrote: On 7/30/08 Daniel Benoy wrote: Also, would the openmoko design team be willing to consider a toggle in the configuration menu between manual and automatic? What we want is for people to add their own configuration options to menus in the form of packages installable from the Installer. This is why we remove functionality. So we can focus on how to make sure our products are extensible. This seems like a bullshit answer to me. Taking functionality away doesn't improve the FR. It makes it less useful. Are you guys deaf or something? Haven't you hear the screams from the people who plonked down their cold hard cash for your product about this reduction in functionality? Or are you just so damn arrogant you think its your way or the highway? If the functionality was there and you felt it should be an option, YOU should have made it one! But thats not what you did. You made it difficult for a programmer to temporarily bring it back, and no way to make it a user selectable option. bah!! Scott ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Or is Sean saying that this would be an option if it was in the form of a package, so if the package was built (by the community) then you would have the choice to toggle or not to toggle? I am assuming that functionality was removed so that it can be an installable option and not a default. Sean? Maybe asking for more information on why, or a more in-depth explanation would be appropriate. Tone down the negativity and just post the question. Constructive criticism is needed for things to move forward, but you can at least be respectfull. I think if OM answered you in the same rhetoric you are asking questions and throwing flames that you would find it offensive. Yes, things need to be improved and yes things are not exactly how everyone wants them. OM has as least opened this up so your input can be received NOW, they could have kept this completely closed for the next year and we would still all be waiting... People need to stop biting the hand that feeds you. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
People need to stop biting the hand that feeds you. he bit the other hand, actually. *scnr* ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Open Source is more than that, do you all propose OM to sell their Software bound to the Hardware? I fear you thing too much in the old fashined way of MObile COmmunication. The Freerunner is a piece of Hardware *YOU DECIDE* what software you want to run on it FSO ASU 2007.1 2007.2, SHR, ASDF or something YOU HAVE created *FREE YOUR CHOISE* Think of your pc I assume the percentage of the people on this list is really high who dislike Microsoft's politics and the fact that nearly every OEM pc comes up with Vista. Think of opensource projects, the most of then started within a comunity, not a company. If you think 2007.2 is not enouth and you feel neglected by OM Ltd. do it yourselves. YOU can't expect a project starting from 0 full speed within *ONE MONTH*! When you bought the FR nobody told you: Okay, right now the SW is really buggy, but I swear within a month, it is gonna be perfect. So be patient, put your power to develop the project, not to complain that some metaphors are better than others or come up with ideas not abuses. be friendly, stop expecting the very best for YOU, be grateful, relax, code, relax, come up with great ideas (like tangoGPS) relax, communicate, stop abusing, free your choice http://freeyourphone.de Scott schrieb: Sean Moss-Pultz wrote: On 7/30/08 Daniel Benoy wrote: Also, would the openmoko design team be willing to consider a toggle in the configuration menu between manual and automatic? What we want is for people to add their own configuration options to menus in the form of packages installable from the Installer. This is why we remove functionality. So we can focus on how to make sure our products are extensible. This seems like a bullshit answer to me. Taking functionality away doesn't improve the FR. It makes it less useful. Are you guys deaf or something? Haven't you hear the screams from the people who plonked down their cold hard cash for your product about this reduction in functionality? Or are you just so damn arrogant you think its your way or the highway? If the functionality was there and you felt it should be an option, YOU should have made it one! But thats not what you did. You made it difficult for a programmer to temporarily bring it back, and no way to make it a user selectable option. bah!! Scott ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Thursday, 31. July 2008 05:24:45 Josh Monson wrote: Or is Sean saying that this would be an option if it was in the form of a package, so if the package was built (by the community) then you would have the choice to toggle or not to toggle? I am assuming that functionality was removed so that it can be an installable option and not a default. Bingo ! :-) Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Marek Lindner wrote: On Thursday, 31. July 2008 05:24:45 Josh Monson wrote: Or is Sean saying that this would be an option if it was in the form of a package, so if the package was built (by the community) then you would have the choice to toggle or not to toggle? I am assuming that functionality was removed so that it can be an installable option and not a default. Bingo ! :-) This might be a desirable goal, but people don't like it if they have to spend days writing the package that's required to bring the functionality back (which so far no one has even tried doing apparently) I don't think anyone would have complained if you had created that package yourself (since, presumably, you're well qualified to do it) and made it available on the standard repo. Right now the way to bring the keyboard back is to dig into the wiki, decompile a theme, modify it, recompile it. A bit harder than installing a package. So: pretty please, could you create a package to add the option? Could you, in the future, when you remove functionality (to make it optional), create a package to get the functionality back? Or at least warn in advance that such a package is needed, so that the community can build the package if you don't have time? Thanks! -- Charles-Henri ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
And while Openmoko is working on their own framework, I have to agree with many other voices: knowing which platform to develop for, as a developer myself, is confusing. I don't like the thought of having to write multiple versions of an application that caters to GTK and Qt separately, although I recall that the FSO framework is trying to bridge that gap. But I also don't want to have to market my application as only works on 2007.2/FSO because I use GTK because that's the route I chose to build my app. More important to note is the hassles involved in *testing* for all the differing platforms. I've got lofty dreams that my applications might actually be worth it to someone. But if I have to support them on all 4 different platforms, thats 4 more phones I should buy and set up with the different environments .. hmm .. Personally, I signed up to help manage the wiki to make it a better source of information. I'm working on developer tutorials. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Lisa wrote: ~ Folks, ~ I don't need a major design statement for my phone...I just want a (mostly) working phone. There is a point where taking one more thing away doesn't make it simpler any longer, it makes it hard to figure out/work on. Not having a terminal in ASU ( the general style of which I like) and taking the manual keyboard switch out of ASU (which actually WORKS as opposed to the automatic pop up which doesn't) were bad ideas , at least for as long as this thing is going to be in pre-release. I could understand it in a general release, but the people who have it now are EXACTLY the kind of people who would whip it out and noodle around with the terminal during lunch break if they could. I know I would..or if you HAVE to leave them out could someone post easy to follow directions to replace them in the wiki somewhere?? For those of us not gifted with totally amazing programming skills? You mean like this? http://wiki.openmoko.org/wiki/ASU_Keyboard_Toggle -- Charles-Henri ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Mon, 2008-07-28 at 17:14 -0700, ian douglas wrote: And while Openmoko is working on their own framework, I have to agree with many other voices: knowing which platform to develop for, as a developer myself, is confusing. This is exactly the point. Openmoko should be like Ubuntu: integrating what is there and adding here and there a missing link. Ubuntu wouldn't be there where it stands today if there would be an Ubuntu framework. They are just making nice distributions and that is the key of their success. There is no real difference between Ubuntu, Kubuntu and Xubuntu. Gimp (GTK) will run on Kubuntu and Scribus (qt) on Ubuntu and both do run on Xubuntu. However, openmoko-messages will not run on ASU. The Framework idea is a Microsoft idea. Remember the days when you couldn't even uninstall Internet Explorer? It was part of the framework. The success of Linux is based on the freedom of choice. No frameworks there. Last not least: the phonekit of OM2007.2 is dbus based too and can therefore be used with qt, etk or whatever else pleases you. This whole argument that FSO allows cross-toolkit is stale. Well, just lets go back over 99 walls... Marcus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Sean Moss-Pultz wrote: Dear Community Design. This is a long, careful response to Sean's Openmoko on Design post. If one goes back to the beginning of the Terminal for ASU thread, what you find is that several users were just getting things set up and mostly working in ASU and then they upgraded and found numerous things were broken because they no longer had a means of manually bringing up a keyboard. A keyboard that always automatically knows when it is needed sounds great in theory, but prior to that perfect keyboard being implemented, what happened here was that users experienced a degradation in usability and had no obvious means of restoring the lost functionality. They were understandably frustrated by this. At the same time we heard comments from a key developer who indicated that the decision was made above him by unnamed individuals with whom the community has no obvious means of communication, and who apparently don't even listen to the reasonable technical arguments of key developers. This also seemed to reveal something about the internals of Openmoko that weren't expected: development decisions are not entirely made by the developers, but instead they answer to some people who the community cannot readily identify and who the community doesn't know how to interact with or if they even can interact with these decision-makers. This led to another set of questions. Many in the community presumed that they would be permitted to contribute code/ideas/design to the software stack that Openmoko is developing, i.e., ASU, but if there are unnamed designers implementing a private design superstructure that overrides even Openmoko developers, then the usefulness or likelihood of thinking that an ordinary end user could become an important part of that development process seems extremely diminished, if not extinguished. This understandably disappointed developers who had hoped to make such core contributions. When prodded to respond, Openmoko employees indicated a willingness to answer questions. At least the following very specific questions were asked: 1) Who is Openmoko's design department? 2) Many in the community believed that Openmoko wanted the community to contribute code to the core applications/functionality of the software stack. Is this not the case? 3) If the design department is operating from a design document, has it been made public? If so, where? If not, why not? Sean responded with a lengthy email. It illustrated again why he is the CEO. A CEO needs to be focused on the big picture, as was his response. A CEO also needs to point his or her team and the customers towards that vision. Sean's email was great at this. However, I think many in the community just wanted some specific answers to the questions above. Sean's email only partially succeeds at this. We learned: Being open doesn't mean we put the essential ideas behind each product to a public vote. which suggests that there may be some parts of what Openmoko is developing that the community will not have a means of directly participating in, and tends to confirm some of the fears expressed above. But we also learned: We're building an empty vessel for you to fill with your ideas. and Change anything you want to our interface and we will gladly deliver it to everyone. and these suggest that community contributions are welcome, even to the interface, and those contributions will sometimes, at least, become an officially distributed part of the Openmoko interface. So that tends to counteract those fears. And while we didn't get any answer to question (1)--who is the design team?--we were told that an answer to question (3)--is there a design doc?--would require working as an Openmoko employee for several months. I think the implication of this has to be that, No, there isn't a single design document that can be pointed to at this moment that explains every decision made or priority had by the Openmoko team. OK. Fine. Everyone should step back and recognize that the device has not even been on sale for a full month. Maybe some people were expecting from day one to use it as their everyday phone for push email, calendar, and contacts, and web browsing and video/mp3 playback, and GPS applications-galore, all with a bluetooth headset that would be operated by accelerometers or something. But we all recognize now that it's not there yet. So, we all should also recognize that there are a million little (and some big) things that need to be done to get the device to have all the capabilities that its hardware make possible. But the community can have (at least) two distinct ways of helping with that giant TODO list. 1) The community can build applications that run on a framework delivered to us by the Openmoko team; or 2) the community can be directly involved in working on the underlying framework on the device; or 3) both. It was this incident with the keyboard that made several people
Re: Openmoko on Design
A keyboard that always automatically knows when it is needed sounds great in theory, but prior to that perfect keyboard being implemented, what happened here was that users experienced a degradation in usability and had no obvious means of restoring the lost functionality. They were understandably frustrated by this. It should be noted, also, that this degradation in usability occurred not just with the keyboard panel functionality, but with quite a few other things in the OM eco-sphere as well - bluetooth, for example, regressed, somewhere in between 2007.8 and 2008.2, as did audio, as has SDL support, and I think we could really come up with a list of quite a few things that 'sort of almost worked, and then stopped completely being usable' .. It is a sensitivity to this back-stepping that leads me to a more vocal opinion about how the base distro platform is being managed at this time. At the same time we heard comments from a key developer who indicated that the decision was made above him by unnamed individuals with whom the community has no obvious means of communication, and who apparently don't even listen to the reasonable technical arguments of key developers. This also seemed to reveal something about the internals of Openmoko that weren't expected: development decisions are not entirely made by the developers, but instead they answer to some people who the community cannot readily identify and who the community doesn't know how to interact with or if they even can interact with these decision- makers. Thus putting lie to the 'its open, so fix it yourself' argument'. This led to another set of questions. Many in the community presumed that they would be permitted to contribute code/ideas/design to the software stack that Openmoko is developing, i.e., ASU, but if there are unnamed designers implementing a private design superstructure that overrides even Openmoko developers, then the usefulness or likelihood of thinking that an ordinary end user could become an important part of that development process seems extremely diminished, if not extinguished. This understandably disappointed developers who had hoped to make such core contributions. I concur with your excellent conclusion and only wish I could've been more eloquent on this issue personally. Sean's email only partially succeeds at this. Actually, it raised alarm bells, in these quarters. It appeared, to me, to be somewhat of a smoke-cloud in an attempt to provide cover over a situation that is detrimental to the survival of OpenMoko as a whole; not just as a company, but also as a community. It is a CEO's job to provide smoke and mirrors when all else fails. We're building an empty vessel for you to fill with your ideas. and Change anything you want to our interface and we will gladly deliver it to everyone. and these suggest that community contributions are welcome, even to the interface, and those contributions will sometimes, at least, become an officially distributed part of the Openmoko interface. So that tends to counteract those fears. I think this is really more of a feint on the part of an embattled CEO, actually. The two conditions: we reserve certain parts of our system for our own designs, and you can contribute whatever you want and we will distribute it to all and sundry are not compatible. Does not compute. Maybe some people were expecting from day one to use it as their everyday phone for push email, calendar, and contacts, and web browsing and video/mp3 playback, and GPS applications-galore, all with a bluetooth headset that would be operated by accelerometers or something. This is as good a spec as we're going to get, isn't it? Further, a number of developers have repeatedly asked with respect to option (1): How do I design my application to work with so many different stacks? What should I be targeting? Sometimes this gets answered with: Take your pick! The ultimate goal is for all such applications to work regardless, i.e., FSO is supposedly going to run GTK, Qt, or whatever-based apps. But most developers who ask this question don't understand how that is supposed to work and need a little more guidance on how to go about things so that they know that they aren't wasting their time building something that won't end up working. That is, it sounds like these developers NEED some sort of design document so that they better understand where things are headed so that they can do their part. For my part I can help with this - I believe that developer tutorials that demonstrate how to operate in these environments and still produce a viable result are badly needed, so I am continuing the work I started with my DraftNotes last year, and will expand this to include: 1. How to set up a compile-onboard environment that works for new apps development, thus avoiding
Re: Openmoko on Design
On Tue, 2008-07-29 at 00:35 -0700, Brian C wrote: [snip lots of very clever thoughts] So, I'll ask again: does Openmoko intend to allow direct code contributions by community members to core components of the ASU/FSO frameworks? It would be better to get rid of this whole framework concept and doing what Sean is constantly talking about: freedom. Freedom of choice. The framework means tying the applications to the system level which is like tying Firefox to Apache. No developer who is sane in his mind will want to marry a whole PIM API just for sending an SMS. And FSO is essentially a newly invented, unstable and immature PIM API. This is so much like Microsoft. And there are already plenty of PIM APIs. Just use one of them, they all work cross toolkit. The gsmd needs a libgsmd and on top of this implement whatever dbus API you like. This is freedom. This is choice. But by immediately glueing the dbus API to a specific gsmd you forcefully marry all developers to your FSO. End of freedom, end of choice. phonekit is a lot more flexible and future proof than FSO. Due to the nature of dbus it can potentially run side by side with any other 'phonekit'. But the whole point of FSO is to block this out. Why do you want people to rip phonekit out of OM2007.2? It is not your business anyway if you stopped development of OM2007.2. The problem is not ETK, not qtopia, not GTK. The problem is framework and FSO. This whole strength of Linux is separation of components. Do one thing and do it well. Why willfully destroy this great concept of success? Openmoko should concentrate on kernel and driver work, power management and working hardware and a basic set of apps. All this is mostly there with OM2007.2 and now energy is better spend on doing thousand of little improvements than starting again from scratch. Marcus - developer of tangoGPS. I know what I'm talking about. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Hi, At the same time we heard comments from a key developer who indicated that the decision was made above him by unnamed individuals with whom the community has no obvious means of communication, and who apparently don't even listen to the reasonable technical arguments of key developers. Openmoko always avoided all kind of formal structures. Thus we don't have such a thing as key or core developer - a developer would be better. This also seemed to reveal something about the internals of Openmoko that weren't expected: development decisions are not entirely made by the developers, but instead they answer to some people who the community cannot readily identify and who the community doesn't know how to interact with or if they even can interact with these decision-makers. May be it revealed that Openmoko itself is diverse as well. That some developers have different opinions than others. It was this incident with the keyboard that made several people believe option (2) was not available, and even after Sean's message, I still don't believe that we know the answer. So, I'll ask again: does Openmoko intend to allow direct code contributions by community members to core components of the ASU/FSO frameworks? If so, will such community members also have a voice in underlying design decisions that guide that/those framework(s)? if course you can - that is the whole point of Openmoko. The best way is to implement a solution, offer a package to install and let the people play with it. If your idea is convincing we will include it. Openmoko has to trust those members of the community, who prove themselves through actual contributions, to be worthy to give input on larger design issues as well. You got the point ! Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Tue, 29 Jul 2008 10:23:41 +0200, Marcus Bauer [EMAIL PROTECTED] wrote: No developer who is sane in his mind will want to marry a whole PIM API just for sending an SMS. And FSO is essentially a newly invented, unstable and immature PIM API. This is so much like Microsoft. And there are already plenty of PIM APIs. Just use one of them, they all work cross toolkit. ... no i finally got what's your problem with fso. while i in some respects agree with you i otoh are worried by the very limited resources of the freerunner. on my laptop there's plenty of ram, cpu, harddisk to have all kind of apps and their daemons coexisting (but, using linux for over a decade now and coming from an k5-133 cpu, i am still annoyed and worried by the lot of rather needless daemons and background processes, in particular those evolution related ones, only for the lighntning calendar app). the fr is far more limited in this respect, so that same kind of coexistence seems hardly managable. that's where a framework seems sensible to me: a lot of functionality common to all kind of apps is put into a framework and there's no need to run concurrent processes who do basically the same thing, just because gtk uses gconf (or whatever) and etk something else and qt(opia) adds another one. what is your idea to remedy those qualms? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 29 Jul 2008, at 09:23, Marcus Bauer wrote: ... Openmoko should concentrate on kernel and driver work, power management and working hardware and a basic set of apps. ... +1 As Openmoko push more open hardware out the door, people will come running to do cool stuff on it. It's the blue sky talk of evoking innovation, actualizing contributions and imagination resources that is building excitement about Openmoko and leading to disappointment. Honestly, if Openmoko said the Freerunner is a free, open, Linux- based mobile phone that runs Trolltech's good old Qtopia phone software then people would still be queuing up to buy it. oh, and by the way we're also developing some software of our own and you can try the open alpha if you want to would be better than this building the future sort of stuff - although the latter phrase strictly indicates it's not ready yet, it's far more evocative and emotional. We think we see our dreams *today* - no wonder people are peeved when they're dashed. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Tuesday 29 July 2008, Marek Lindner wrote: Hi, At the same time we heard comments from a key developer who indicated that the decision was made above him by unnamed individuals with whom the community has no obvious means of communication, and who apparently don't even listen to the reasonable technical arguments of key developers. Openmoko always avoided all kind of formal structures. Thus we don't have such a thing as key or core developer - a developer would be better. Whether the term is 'key developer' or just 'a developer' is irrelevant. The issue is the total lack of communication over removal of a function many in the community, not to mention said developer, have good technical reasons to see as absolutely vital. This also seemed to reveal something about the internals of Openmoko that weren't expected: development decisions are not entirely made by the developers, but instead they answer to some people who the community cannot readily identify and who the community doesn't know how to interact with or if they even can interact with these decision-makers. May be it revealed that Openmoko itself is diverse as well. That some developers have different opinions than others. Diversity of opinion is fine and expected, but we needed to hear what the other opinions were! It was this incident with the keyboard that made several people believe option (2) was not available, and even after Sean's message, I still don't believe that we know the answer. So, I'll ask again: does Openmoko intend to allow direct code contributions by community members to core components of the ASU/FSO frameworks? If so, will such community members also have a voice in underlying design decisions that guide that/those framework(s)? if course you can - that is the whole point of Openmoko. The best way is to implement a solution, offer a package to install and let the people play with it. If your idea is convincing we will include it. I thought that was the whole point too, but your answer seems only to answer one of the two questions. You seem to be saying 'Of course you can submit code, and if we like it we'll use it' but saying nothing about whether the community has a voice in the decision. It would be helpful to know before embarking on implementation whether the idea conflicts with one or more of the unstated ideals by which inclusion may be judged. Openmoko has to trust those members of the community, who prove themselves through actual contributions, to be worthy to give input on larger design issues as well. You got the point ! I think so, but I think the rest of the paragraph, particularly the preceding sentence, was at least as important. Since you snipped it I'm not sure you feel the same way. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
2008/7/29 Marek Lindner [EMAIL PROTECTED]: Hi, At the same time we heard comments from a key developer who indicated that the decision was made above him by unnamed individuals with whom the community has no obvious means of communication, and who apparently don't even listen to the reasonable technical arguments of key developers. Openmoko always avoided all kind of formal structures. Thus we don't have such a thing as key or core developer - a developer would be better. But you do have a design team, according to Rasterman. This also seemed to reveal something about the internals of Openmoko that weren't expected: development decisions are not entirely made by the developers, but instead they answer to some people who the community cannot readily identify and who the community doesn't know how to interact with or if they even can interact with these decision-makers. May be it revealed that Openmoko itself is diverse as well. That some developers have different opinions than others. Out of curiosity, how many of these developers use an Openmoko phone as their primary phone? Do these differences of opinion tend to fall on the same boundaries? Still, nobody has mentioned why the design team can't be contacted or identified. Openmoko has to trust those members of the community, who prove themselves through actual contributions, to be worthy to give input on larger design issues as well. You got the point ! Strange, I read this as Openmoko has not been, but should in the future, trust those members I haven't been here long enough to determine which is the case. Maybe the company hasn't, either. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Charles, While that is a means of bringing the keyboard button back, thats just too damn hard! And I have to do that all over again if I upgrade! Needs to be a simple configuration setting. Scott Charles-Henri Gros wrote: You mean like this? http://wiki.openmoko.org/wiki/ASU_Keyboard_Toggle signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Tuesday, 29. July 2008 19:19:10 Al Johnson wrote: Whether the term is 'key developer' or just 'a developer' is irrelevant. The issue is the total lack of communication over removal of a function many in the community, not to mention said developer, have good technical reasons to see as absolutely vital. Unfortunately, this tiny difference is important because it sounded like Even THE key developer (and god knows who else) objected and still you did it!. Diversity of opinion is fine and expected, but we needed to hear what the other opinions were! True, and you did hear it. I thought that was the whole point too, but your answer seems only to answer one of the two questions. You seem to be saying 'Of course you can submit code, and if we like it we'll use it' but saying nothing about whether the community has a voice in the decision. It would be helpful to know before embarking on implementation whether the idea conflicts with one or more of the unstated ideals by which inclusion may be judged. You should realize that we (Openmoko) are vastly outnumbered by the tasks on our ToDo list and the mails we have to process. For us it is very hard to grep out the genius and doable ideas - it is just too much ! But if you can provide a working prototype of your idea you can be sure that we seriously look at it. We simply install it, play with it and eventually get infected by it. In the end we are geeks as well and like to see cool stuff. :-) I think so, but I think the rest of the paragraph, particularly the preceding sentence, was at least as important. Since you snipped it I'm not sure you feel the same way. Do you mean that sentence: we are paid by openmoko to do what we are told to do by the design department and that is what we then do. If that's the state of things for paid developers, then community contributors have even less hope. Again, this is the statement from a single developer - I _definitely_ don't agree with that. This is simply not the way it is. Honestly, I have never seen a company that gives so much freedom to its employees. Sometimes I even have the feeling this is more a democracy instead of a business here. :-) Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Chris Wright wrote: snipped Still, nobody has mentioned why the design team can't be contacted or identified. Posted to the list a couple days ago: http://lists.openmoko.org/pipermail/community/2008-July/023806.html We can be contacted, just wasn't using an openmoko email at the time I wrote it. - Will ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Tuesday, 29. July 2008 20:17:00 Chris Wright wrote: But you do have a design team, according to Rasterman. Of course we have. How do you think we are trying to get to a device that is ready for end user ? And this is just the beginning. We will work with more designers for the UI, the housing, etc to continue the direction towards the mass market. But that does not mean all that is perfect right from the beginning or that we don't listen to constructive criticism. Please help us making it better by _demonstrating_ a superior solution not by sending more emails. Out of curiosity, how many of these developers use an Openmoko phone as their primary phone? What do you mean with these developers ? Everybody certainly has a different opinion than others on something. Do these differences of opinion tend to fall on the same boundaries? I don't get what you trying to say here. Still, nobody has mentioned why the design team can't be contacted or identified. Sorry but this is just not true. I don't get why you follow this childish witch-hunt game. Strange, I read this as Openmoko has not been, but should in the future, trust those members I haven't been here long enough to determine which is the case. Maybe the company hasn't, either. Meant was: Openmoko pays much more attention to installable solutions and listens to hackers that provide those instead to people that complain all day long but don't get their hands dirty. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openmoko on Design
Jay, you need to chill. You are being really disrepectful to a fellow human who has worked tirelessly on this stuff for years. I know you have some passion about this too, but you need to dial down the rhetoric a notch or 52. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jay Vaughan Sent: Monday, July 28, 2008 1:21 PM To: [EMAIL PROTECTED]; List for Openmoko community discussion Subject: Re: Openmoko on Design Let's start simple. And grow. I know we can get there! Get where exactly? Got coordinates for that destination? By the sounds of it, not really .. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openmoko on Design
That's really perceptive. If you go read Morse Peckham's book http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/0805201424 You will understand how museuems and gallery's function; and, Sean's words will strike you more deeply. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of david varnes Sent: Monday, July 28, 2008 5:32 PM To: [EMAIL PROTECTED]; List for Openmoko community discussion Subject: Re: Openmoko on Design On Tue, Jul 29, 2008 at 4:22 AM, Sean Moss-Pultz [EMAIL PROTECTED] wrote: [snip] Think of our products as museums. We're building the environment. I re-read Sean's post a couple of time (like a few people I am guessing :-) For some of us 'museum' may have an old/musty connotation. When I put art gallery everywhere he says museum, it landed in my my ears very differently :-) [snip] Like Will already said, by removing a manual keyboard button we are forced to self-organize using the resources in our environment. [snip] A lot of re-organizing in the real world comes with some pain .. but often, less is more in genuinely good design. This is an interesting ride ... it's good to be able to ride along. Interesting post Sean, thanks! davidv ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
No bad intentions for snipping, Just trying to get to the facts: Brian C wrote: snipped 1) Who is Openmoko's design department? That would be: William Lai - PM Regina Kim - Testing Wendy Hung - Testing 2) Many in the community believed that Openmoko wanted the community to contribute code to the core applications/functionality of the software stack. Is this not the case? This is still the case, yes. 3) If the design department is operating from a design document, has it been made public? If so, where? If not, why not? Design doc uploaded (sometime in April) http://people.openmoko.org/ninjutsu/freerunner1.4.swf Posted by Ian Darwin in May http://lists.openmoko.org/pipermail/community/2008-May/017504.htm Feature Plan tracking http://wiki.openmoko.org/wiki/ASU_Feature_Plan Bug Tracking: https://docs.openmoko.org/trac/milestone/ASU You get the point. Sean responded with a lengthy email. It illustrated again why he is the CEO. A CEO needs to be focused on the big picture, as was his response. A CEO also needs to point his or her team and the customers towards that vision. Sean's email was great at this. However, I think many in the community just wanted some specific answers to the questions above. Read Above. snipped And while we didn't get any answer to question (1)--who is the design team?--we were told that an answer to question (3)--is there a design doc?--would require working as an Openmoko employee for several months. Yes and No. Ian Darwin found my asu flash doc, and I sure as hell don't remember telling him where it was.. I think the implication of this has to be that, No, there isn't a single design document that can be pointed to at this moment that explains every decision made or priority had by the Openmoko team. OK. Fine. Every decision? No. I can try to help, but I barely remember what I had for breakfast.. snipped But the community can have (at least) two distinct ways of helping with that giant TODO list. 1) The community can build applications that run on a framework delivered to us by the Openmoko team; Yes. or 2) the community can be directly involved in working on the underlying framework on the device; Yes. or 3) both. Yes. It was this incident with the keyboard that made several people believe option (2) was not available, and even after Sean's message, I still don't believe that we know the answer. So, I'll ask again: does Openmoko intend to allow direct code contributions by community members to core components of the ASU/FSO frameworks? Yes. If so, will such community members also have a voice in underlying design decisions that guide that/those framework(s)? It already is. We've offered a couple of different solutions to community requests that were declined by, well, engineering. One of them was: * create a package to be installed through installer adding manual qwerty button to illume theme. Further, a number of developers have repeatedly asked with respect to option (1): How do I design my application to work with so many different stacks? What should I be targeting? Sometimes this gets answered with: Take your pick! The ultimate goal is for all such applications to work regardless How do I design a website for Safari, Firefox, Internet Explorer? Think about it. Openmoko is to mobile Firefox is to internet 'Firefox' supports html xhtml dhtml php java flash ... I am by no means a technical person, does this help? Again: it's been less than a month that the device has been on sale. I believe the Openmoko team has clearly been working overtime and doing a great job at an overwhelming-sized task. Thank you. Everyone take a deep breath and let's find ways to work together. Sure. - Will ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
2008/7/29 Marek Lindner [EMAIL PROTECTED]: On Tuesday, 29. July 2008 20:17:00 Chris Wright wrote: But you do have a design team, according to Rasterman. Of course we have. How do you think we are trying to get to a device that is ready for end user ? And this is just the beginning. We will work with more designers for the UI, the housing, etc to continue the direction towards the mass market. But that does not mean all that is perfect right from the beginning or that we don't listen to constructive criticism. Please help us making it better by _demonstrating_ a superior solution not by sending more emails. Where I work, the design team is the same as the development team. Out of curiosity, how many of these developers use an Openmoko phone as their primary phone? What do you mean with these developers ? Everybody certainly has a different opinion than others on something. Then it's vacuous to say so. Do these differences of opinion tend to fall on the same boundaries? I don't get what you trying to say here. Something as simple as a keyboard button -- well, users were complaining about its lack very quickly. If the design team were also users, then they would have insisted that the error be fixed. Still, nobody has mentioned why the design team can't be contacted or identified. Sorry but this is just not true. I don't get why you follow this childish witch-hunt game. Because you were responding to this quote: This also seemed to reveal something about the internals of Openmoko that weren't expected: development decisions are not entirely made by the developers, but instead they answer to some people who the community cannot readily identify and who the community doesn't know how to interact with or if they even can interact with these decision-makers. And your response was in no way related. I was merely pointing that out. Strange, I read this as Openmoko has not been, but should in the future, trust those members I haven't been here long enough to determine which is the case. Maybe the company hasn't, either. Meant was: Openmoko pays much more attention to installable solutions and listens to hackers that provide those instead to people that complain all day long but don't get their hands dirty. Okay. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openmoko on Design
Thanks marek. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Lindner Sent: Tuesday, July 29, 2008 10:06 AM To: List for Openmoko community discussion Subject: Re: Openmoko on Design On Tuesday, 29. July 2008 19:19:10 Al Johnson wrote: Whether the term is 'key developer' or just 'a developer' is irrelevant. The issue is the total lack of communication over removal of a function many in the community, not to mention said developer, have good technical reasons to see as absolutely vital. Unfortunately, this tiny difference is important because it sounded like Even THE key developer (and god knows who else) objected and still you did it!. Diversity of opinion is fine and expected, but we needed to hear what the other opinions were! True, and you did hear it. I thought that was the whole point too, but your answer seems only to answer one of the two questions. You seem to be saying 'Of course you can submit code, and if we like it we'll use it' but saying nothing about whether the community has a voice in the decision. It would be helpful to know before embarking on implementation whether the idea conflicts with one or more of the unstated ideals by which inclusion may be judged. You should realize that we (Openmoko) are vastly outnumbered by the tasks on our ToDo list and the mails we have to process. For us it is very hard to grep out the genius and doable ideas - it is just too much ! But if you can provide a working prototype of your idea you can be sure that we seriously look at it. We simply install it, play with it and eventually get infected by it. In the end we are geeks as well and like to see cool stuff. :-) I think so, but I think the rest of the paragraph, particularly the preceding sentence, was at least as important. Since you snipped it I'm not sure you feel the same way. Do you mean that sentence: we are paid by openmoko to do what we are told to do by the design department and that is what we then do. If that's the state of things for paid developers, then community contributors have even less hope. Again, this is the statement from a single developer - I _definitely_ don't agree with that. This is simply not the way it is. Honestly, I have never seen a company that gives so much freedom to its employees. Sometimes I even have the feeling this is more a democracy instead of a business here. :-) Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Wed, 30 Jul 2008 01:05:35 +0800 Marek Lindner [EMAIL PROTECTED] babbled: Do you mean that sentence: we are paid by openmoko to do what we are told to do by the design department and that is what we then do. If that's the state of things for paid developers, then community contributors have even less hope. Again, this is the statement from a single developer - I _definitely_ don't agree with that. This is simply not the way it is. Honestly, I have never seen a company that gives so much freedom to its employees. Sometimes I even have the feeling this is more a democracy instead of a business here. :-) oooh.. i have to make this clear. this is EXACTLY how it has become. i have done things differently in the past - because that was just what i saw needed doing. i have disagreed. i have changed things to make things work better (imho). and the response to this has been grumble grumble - we don't like you wasting all your time on things not in the design, but you just do whatever you want to anyway because you can (and implied is the we don't like what you do - but have very little ability to stop it). in fact even you were there at the time that was said. you have missed the other time it was very explicitly stated to me in a meeting. i have rescinded my freedom to do what i think is right, and do what i am instructed. those unhappy with my doing things different to/outside of the design do not want to argue - i don't either. so to cease arguments, i do as instructed. you joined openmoko after we started on ASU and have missed a lot of history. i also will disagree with openmoko giving developers so much freedom - i have worked with significantly more freedom in the past at linux/open source companies. much more. openmoko is middle-of-the-road in this department, and not an outstanding beacon, neither is it a sweatshop dungeon :) -- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Many thanks for the direct answers. This is what I've been hoping for. I'll snip most of it to keep the length reasonable. On Tuesday 29 July 2008, William Lai wrote: No bad intentions for snipping, Just trying to get to the facts: Brian C wrote: Snipped 3) If the design department is operating from a design document, has it been made public? If so, where? If not, why not? Design doc uploaded (sometime in April) http://people.openmoko.org/ninjutsu/freerunner1.4.swf Posted by Ian Darwin in May http://lists.openmoko.org/pipermail/community/2008-May/017504.htm Just in case anyone wonders why it comes back not found, typo corrected http://lists.openmoko.org/pipermail/community/2008-May/017504.html Feature Plan tracking http://wiki.openmoko.org/wiki/ASU_Feature_Plan Bug Tracking: https://docs.openmoko.org/trac/milestone/ASU You get the point. I think so. There's some documentation but nothing particularly detailed, and details weren't set in stone as of Ian's post in May when the keyboard toggle existed. It has been public, but perhaps not widely known about, for quite some time. Comments in the bug tracker reference a discussion on the openmoko-devel list which I assume to be one of these: http://www.mail-archive.com/openmoko-devel%40lists.openmoko.org/msg02263.html http://www.mail-archive.com/openmoko-devel%40lists.openmoko.org/msg01542.html Big chunk of snippage... If so, will such community members also have a voice in underlying design decisions that guide that/those framework(s)? It already is. We've offered a couple of different solutions to community requests that were declined by, well, engineering. One of them was: * create a package to be installed through installer adding manual qwerty button to illume theme. The only suggestion I remember was that the community fork illume. Is this a different take on the same suggestion, or a different suggestion? What was the other option? And what was the objection to providing it as a configuration option with the default being off, as proposed on this list? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Is it feasible to have illume detect that an application isn't capable/interested in sending the signal to bring up the keyboard? Also, would the openmoko design team be willing to consider a toggle in the configuration menu between manual and automatic? I have a portable bluetooth keyboard (Something which I assume the design team wants to eventually support out-of-the-box) and it's annoying for the on screen keyboard to ever come up for me unless I specifically ask for it because it reduces my usable window space, so in my case, I would prefer to set it to manual. (And I have modified my illume theme to achieve that) If I didn't have a bluetooth keyboard, I'd prefer for it to be automatic, but provide me with a manual toggle (automatically) when I'm currently looking at software which doesn't know how to ask for the keyboard.. I think this is a good compromise, and in the best interests of the platform because of the value of quick-and-dirty linux X11 application porting, but at the same time end-consumers who only use pre-installed software will never even know the toggle is there, so the designers should be happy. I hope I'm not adding to the flame war :( I really appreciate the hard work and money that openmoko is putting into this project for me and the rest of the community .. and I don't want them to feel underappreciated as a result of all the nitpicks. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Wednesday, 30. July 2008 04:57:27 Chris Wright wrote: Where I work, the design team is the same as the development team. May I ask where you work and what kind of consumer products you are creating ? Something as simple as a keyboard button -- well, users were complaining about its lack very quickly. If the design team were also users, then they would have insisted that the error be fixed. They _are_ users and kept complaining all the time why we have to push the damn button. The software should know that we want to type something. Yes, they are no engineers but I try to see that as a plus not a burden. Their perception is to have software that gets invisible while enabling the user to get the real job done and not the other way round. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Tue, 29 Jul 2008 20:56:23 -0400 Daniel Benoy [EMAIL PROTECTED] babbled: Is it feasible to have illume detect that an application isn't capable/interested in sending the signal to bring up the keyboard? with the matchbox protocol - it is not possible. with the new protocol i put in (which uses window properties) it is possible to know. the app will explicitly set a property on its window indicating its desired keyboard state. Also, would the openmoko design team be willing to consider a toggle in the configuration menu between manual and automatic? I have a portable bluetooth keyboard (Something which I assume the design team wants to eventually support out-of-the-box) and it's annoying for the on screen keyboard to ever come up for me unless I specifically ask for it because it reduces my usable window space, so in my case, I would prefer to set it to manual. (And I have modified my illume theme to achieve that) actually i just committed code that in theory detects extra keyboards (bt, usb - not tested) and forcibly disables and vkbd if you have one attached. i know - it'd be nice to even have this behavior a conifg value and able to be overridden... that's a matter of code - enough of it, but for now, it probably covers 99% of use cases in the event of a bt/usb kbd... but as i said - it's untested right now (it works - if i fake it - so the code works, but detection of the keyboard is still untested - it should work... in theory). it's in latest rev of illume in svn, no nightly build or update to asu.dev git... yet... will do soon. If I didn't have a bluetooth keyboard, I'd prefer for it to be automatic, but provide me with a manual toggle (automatically) when I'm currently looking at software which doesn't know how to ask for the keyboard.. I think this is a good compromise, and in the best interests of the platform because of the value of quick-and-dirty linux X11 application porting, but at the same time end-consumers who only use pre-installed software will never even know the toggle is there, so the designers should be happy. I hope I'm not adding to the flame war :( I really appreciate the hard work and money that openmoko is putting into this project for me and the rest of the community .. and I don't want them to feel underappreciated as a result of all the nitpicks. it's up to the designers to say if they want it or not. me - personally, agree. i also don't see the harm in keeping the toggle if the app can do it automatically anyway - as you may not want to edit anything - just browse (eg web browser - the javascript forces a editable field to be focused - thus the kbd pops up - but you have no desire to edit - you just want to read... so tap the button to pop it down). but that's just my opinion. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Wednesday 30 July 2008, Marek Lindner wrote: On Wednesday, 30. July 2008 04:57:27 Chris Wright wrote: Something as simple as a keyboard button -- well, users were complaining about its lack very quickly. If the design team were also users, then they would have insisted that the error be fixed. They _are_ users and kept complaining all the time why we have to push the damn button. The software should know that we want to type something. Yes, they are no engineers but I try to see that as a plus not a burden. Their perception is to have software that gets invisible while enabling the user to get the real job done and not the other way round. I agree with everything you say here. The keyboard should just appear when I want it and disappear when I don't. The absence of a manual override means that whenever it gets it wrong I can't correct it, the worst case being when I need to enter something but the keyboard doesn't appear. Conversely the presence of a manual override causes no problem even if it is never needed. The keyboard failing to appear is not a hypothetical scenario. Without manual intervention minimo was unusable because the keyboard didn't appear when the cursor was placed for URL entry. This is likely to be an issue with other apps that don't have a specific openmoko port, and we shouldn't have to create such a port just to use an otherwise capable app on openmoko. Other issues include the keyboard appearing when an edit field has focus although I don't want to edit it, keyboard appearing and disappearing frequently if a form contains mixed input types, or appearing over the top of the field to be edited. The field having focus although editing is not required is probably impossible to detect because the answer depends on the opinion of the user at the time. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Wednesday, 30. July 2008 10:18:33 Al Johnson wrote: I agree with everything you say here. The keyboard should just appear when I want it and disappear when I don't. The absence of a manual override means that whenever it gets it wrong I can't correct it, the worst case being when I need to enter something but the keyboard doesn't appear. Conversely the presence of a manual override causes no problem even if it is never needed. The keyboard failing to appear is not a hypothetical scenario. Without manual intervention minimo was unusable because the keyboard didn't appear when the cursor was placed for URL entry. This is likely to be an issue with other apps that don't have a specific openmoko port, and we shouldn't have to create such a port just to use an otherwise capable app on openmoko. Other issues include the keyboard appearing when an edit field has focus although I don't want to edit it, keyboard appearing and disappearing frequently if a form contains mixed input types, or appearing over the top of the field to be edited. The field having focus although editing is not required is probably impossible to detect because the answer depends on the opinion of the user at the time. I understand your points and they all are valid. How do we address them ? That brings us back to Seans mail. Openmoko will provide the minimum set of applications and basic functionality that empowers ordinary users to use the phone. We will make sure that these applications work well with the environment we provide. This is an ongoing process we just started compared to many established phone systems. Feel invited to extend that basic system through packages that can be installed. If you install an application that hasn't been ported to the Openmoko platform and does not support the keyboard you also should install the manual keyboard button or you just install a package which deativates the automatic keyboard behaviour right away if you don't like it. We have to realize that the world is very diverse - we wont find a solution which suits for everybody in all the cases. So, we have to make it flexible. Again: This is a process and you can help us with that. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Wed, Jul 30, 2008 at 01:47:29AM +0100, Al Johnson wrote: I'll snip most of it to keep the length reasonable. same here :) On Tuesday 29 July 2008, William Lai wrote: It already is. We've offered a couple of different solutions to community requests that were declined by, well, engineering. One of them was: * create a package to be installed through installer adding manual qwerty button to illume theme. The only suggestion I remember was that the community fork illume. Is this a different take on the same suggestion, or a different suggestion? What was the other option? And what was the objection to providing it as a configuration option with the default being off, as proposed on this list? What we are trying to do: provide a OM repository and a community repository. in this particular case, if in the end the illume still shipped without kbd button, then the community will very likely provide another version of illume called illume-kbd in the community repository. thus you can replace the shipped illume with illume-kbd, and the next upgrade will get the new version of illume-kbd instead of illume, so you don't need to change it again after upgrade. Where we are right at the moment: illume is there. the community repository is not ready yet but we're working on it. the dependency handling of replacing the shipped illume with illume-kbd is not ready yet but we're working on it. My personal comment on this: if the illume is so much more popular then illume-kdb (theoretically we can know that from the repository log) or the other way around then you bet that fact will be very effective in OM. ;) Regards, John ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Scott wrote: Charles, While that is a means of bringing the keyboard button back, thats just too damn hard! And I have to do that all over again if I upgrade! Needs to be a simple configuration setting. Agreed, but I was just replying to that part: if you HAVE to leave them out could someone post easy to follow directions to replace them in the wiki somewhere?? For those of us not gifted with totally amazing programming skills? -- Charles-Henri ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 7/29/08 ian douglas wrote: I feel that Sean has just given us (or perhaps just reiterated what should have already been known), as a community, the means to empower ourselves to help on *everything* about the Openmoko project as a whole. We wanted an open platform, and it's been given to us. We're *all* part of that design. Thank you Ian. Very well said. -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 7/29/08 david varnes wrote: On Tue, Jul 29, 2008 at 4:22 AM, Sean Moss-Pultz [EMAIL PROTECTED] wrote: [snip] Think of our products as museums. We're building the environment. I re-read Sean's post a couple of time (like a few people I am guessing :-) For some of us 'museum' may have an old/musty connotation. When I put art gallery everywhere he says museum, it landed in my my ears very differently:-) Marek likes art gallery better, too. I hope this gets the point across. Ryan Paul wrote the following in Ars Technica: Openmoko's potential for success will be heavily predicated on the ability to turn choice and diversity into an asset rather than an impediment. This is the essense of what we're doing with efforts like FSO (the future framework of ASU and more) and our Installer. We (Openmoko) focus on making a very attractive museum or, if you prefer, art gallery. We embracing the need to figure out *what needs to be made the most simple*. We then try to focus on what is needed to grow and diversify human interests as they change. -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openmoko on Design
/me stands and applauds -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Moss-Pultz Sent: Monday, July 28, 2008 1:22 PM To: [EMAIL PROTECTED]; List for OpenMoko community discussion Subject: Openmoko on Design Dear Community snip -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sean Moss-Pultz wrote: Change anything you want to our interface and we will gladly deliver it to everyone. Your music for sound events. Your themes. Speak with your work, not so much with your emails. Let's organize the best parts of mobile FOSS as packages easily installable for the world. We're not going to build yet another App Store. I think all we must to stop to say: this is not ok, this is not running. OM teams is working on Freerunner, me must to complete. There is a lot of work to do, and OM can't all this alone. All depend by US -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiOHWsACgkQSIAU/I6SkT2FwACgpl2kSBdevjfFARSWcgFI764d H2UAnRR9bhIjE6bvSXU43oG/fUlKQFvv =BaK3 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On 7/29/08 Michele Renda wrote: There is a lot of work to do, and OM can't all this alone. Exactly. This is really the essense of what I want to say. We need your help to organize our environment. We need to focus on this. Flashy design can come later if that's what's wanted. We are open. This is the true uniqueness of our project. From the iron to the eyeballs. We need to make it easy to understand what this means. We still haven't begun to really focus on these questions. What does open mean to normal people? How does Openmoko make open valuable? Let's start simple. And grow. I know we can get there! -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Thanks for an excellent post. It gives me an even better insight into OpenMoko's vision. Thanks for all of the hard work! Cheers Alex. Sean Moss-Pultz wrote, On 28/07/08 19:22: Dear Community Design. Many people seem to expect an explanation of design from Openmoko. This isn't going to happen. At least not today. Design isn't something static that I can stop and say here is exactly what Openmoko wants. 1+1 = 2. We try not to talk so much about features or design styles of future products. For the simple reason that we’re not so sure what they will look like ourselves. Design, for us, is the process in which we start by pursuing a few essential ideas and allow for the final result to come into being. Notice that I am not talking about moving pixels. Nor I'm not talking about colors or fonts. Design, in my opinion, is not about technical skill. It's about personal struggle. It's the process by which you relentlessly force yourself to focus on exposing your essential ideas. This cannot be patched and merged like source codes. Imagine Malevich and Monet each painting half of the same painting. The result would surely depress them both. Being open doesn't mean we put the essential ideas behind each product to a public vote. Being open means we provide you with the tools to change our decisions. Like anything highly creative, design is always highly subjective. Even if I would explain the essential ideas of our products to everyone, they would not make sense in the way I want them to. Because you are only seeing one part of a very intricate long-term plan. You would need to work with us, full time, for many months before Openmoko's vision would really make sense. I can only show you the tangible pieces -- products. Our company is open. You are always invited into this space. Don't forget you are watching serious people work their ass' off. We are mechanics and will certainly yell, Fuck! when we smash our fingers or break things. All engineering is public from day one. It is humanly impossible for us not to show you things that are unfinished, inaccurate, flawed, and even self-destructive at times. But we have faith in what we're doing. Openness is our foundation. It's not a marketing buzzword. So my only question for you is, Do you want to watch, or help?. Because if you want to just stand around and criticize our work, I will have to ask you to leave the shop. People are working here. We're trying to Free your Phone. Stop bashing things like ASU. This is our work and we are in the earliest of stages. We want to share it with you. Understand that we are not even close to satisfied with it in its current state. But we can see the direction and we love how it's coming together. This is the design process in full effect. Think of our products as museums. We're building the environment. Each one different from the next. You'll get all the free art supplies you could imagine because we want you to add your own meaning. You choose: consume, create, or both. Either way you create your own meaning. It's about you. Our design is more like non-design. We try to remove anything obvious. And focus on what's meaningful. We're not trying to launch a carefully crafted message with a bling-filled user interface. We're building an empty vessel for you to fill with your ideas. We focus on making products that are open and simple. Only products that are open can grow as you grow. Only something simple can be used by everyone. My mom can install Firefox plugins. Can your mom personalize your FreeRunner? Like Will already said, by removing a manual keyboard button we are forced to self-organize using the resources in our environment. Resources such as our wiki and our Installer are still badly broken. We need to fix these. We need to make them accessible for normal people. Every element removed is a chance to organize information in ways that are meaningful for others. Whether you like our design or not isn't even the question. You have all the tools you could possibly want to change it. At Openmoko, we're trying as hard as we can to not over design. Could you imagine walking into a museum where the museum itself looked better than the artwork? We're trying to give you the environment to self-organize. Your code. Your ideas. Your emotions. And then share them back with others. The entire point of our Installer is to provide a simple way to bring the excitement and energy of our community into the Neos of normal people. Why else would we invest so much time and money into things like our framework? Or even the little things like opening our CAD files and our schematics? We're building you a museum to showcase the wonderful diversity of this community. It's a foundation for you to stand on. We want your applications. Your ideas in the form of packages of what the buttons can do. Change
Re: Openmoko on Design
On Mon, 28 Jul 2008 22:21:28 +0200 Jay Vaughan [EMAIL PROTECTED] wrote: Let's start simple. And grow. I know we can get there! Get where exactly? Got coordinates for that destination? Maybe Tango GPS can help trace the route? solar.george signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Potential, that is the first word that comes to mind when I think about and play with my freerunner. I spent months absolutely obsessively waiting for the release, but when I first received it I was afraid. The gps issue was all over the mailing list and I was thinking that things weren't working out exactly as I wanted. It is embarrassing that it took me some time to recover from that initial shock (3 days) and to realise that what I held was truly open. Deep down I knew it wouldn't arrive in my hands perfect, but that is the point. One closed device can never be perfect for everyone. Only through customisation and expansion can each one of us make the device perfect for him/herself. And we need not do this in isolation, when we do something cool we can share it, and then others have the *choice* to implement this feature/gimmick/personalisation on their own device, in their own way. I have grown accustomed to companies telling me what looks pretty and how things should work and that is part of what scares me. There is no excuse not to make the freerunner behave exactly the way I want it to. To start settling into the freerunner I flashed ASU (using VMware) this weekend and was amazed at how easy it is to customise. Changed the icons, created new launcher items and linked these to plain-old shell scripts to connect to my home network etc. Installed vte terminal, changed the font size, to summarise: Nothing ground breaking yet, but I did it the way I wanted to and there is a lot of potential. Rock on freerunners! -- View this message in context: http://n2.nabble.com/Openmoko-on-Design-tp587159p587441.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ~ Folks, ~ I don't need a major design statement for my phone...I just want a (mostly) working phone. There is a point where taking one more thing away doesn't make it simpler any longer, it makes it hard to figure out/work on. Not having a terminal in ASU ( the general style of which I like) and taking the manual keyboard switch out of ASU (which actually WORKS as opposed to the automatic pop up which doesn't) were bad ideas , at least for as long as this thing is going to be in pre-release. I could understand it in a general release, but the people who have it now are EXACTLY the kind of people who would whip it out and noodle around with the terminal during lunch break if they could. I know I would..or if you HAVE to leave them out could someone post easy to follow directions to replace them in the wiki somewhere?? For those of us not gifted with totally amazing programming skills? ~Oh, and my general opinion is, if there is no bitching, no drama and no complaints...if no one stirs the shit and throws tantrums-it ain't Open Source. So get used to it everyone..if NONE of it was happening, guess what? We'd all be working for (shudder) Microsoft or something. ~Lisa Waddell ~ :) Queen of the Drama Zone Sean Moss-Pultz wrote: | | | Dear Community | | | Design. | | Many people seem to expect an explanation of design from Openmoko. This isn't going to happen. At least not today. Design isn't something static that I can stop and say here is exactly what Openmoko wants. 1+1 = 2. We try not to talk so much about features or design styles of future products. For the simple reason that we’re not so sure what they will look like ourselves. Design, for us, is the process in which we start by pursuing a few essential ideas and allow for the final result to come into being. Notice that I am not talking about moving pixels. Nor I'm not talking about colors or fonts. Design, in my opinion, is not about technical skill. It's about personal struggle. It's the process by which you relentlessly force yourself to focus on exposing your essential ideas. This cannot be patched and merged like source codes. Imagine Malevich and Monet each painting half of the same painting. The result would surely depress them both. Being open doesn't mean we put the essential ideas behind each product to a public vote. Being open means we provide you with the tools to change our decisions. | | Like anything highly creative, design is always highly subjective. Even if I would explain the essential ideas of our products to everyone, they would not make sense in the way I want them to. Because you are only seeing one part of a very intricate long-term plan. You would need to work with us, full time, for many months before Openmoko's vision would really make sense. I can only show you the tangible pieces -- products. Our company is open. You are always invited into this space. Don't forget you are watching serious people work their ass' off. We are mechanics and will certainly yell, Fuck! when we smash our fingers or break things. All engineering is public from day one. It is humanly impossible for us not to show you things that are unfinished, inaccurate, flawed, and even self-destructive at times. But we have faith in what we're doing. Openness is our foundation. It's not a marketing buzzword. So my only question for you is, Do you want to watch, or help?. Because if you want to just stand around and criticize our work, I will have to ask you to leave the shop. People are working here. We're trying to Free your Phone. Stop bashing things like ASU. This is our work and we are in the earliest of stages. We want to share it with you. Understand that we are not even close to satisfied with it in its current state. But we can see the direction and we love how it's coming together. This is the design process in full effect. | | Think of our products as museums. We're building the environment. Each one different from the next. You'll get all the free art supplies you could imagine because we want you to add your own meaning. You choose: consume, create, or both. Either way you create your own meaning. It's about you. Our design is more like non-design. We try to remove anything obvious. And focus on what's meaningful. We're not trying to launch a carefully crafted message with a bling-filled user interface. We're building an empty vessel for you to fill with your ideas. We focus on making products that are open and simple. Only products that are open can grow as you grow. Only something simple can be used by everyone. | | My mom can install Firefox plugins. Can your mom personalize your FreeRunner? | | Like Will already said, by removing a manual keyboard button we are forced to self-organize using the resources in our environment. Resources such as our wiki and our Installer are still badly broken. We need to
Re: Openmoko on Design
ezuall wrote: Potential, that is the first word that comes to mind when I think about and play with my freerunner. I spent months absolutely obsessively waiting for the release, but when I first received it I was afraid. I agree, there's unlimited potential. To be honest, I was all hyped about the Freerunner, even throughout the beta testing period before they became available for purchase, and gladly took the risk of making a purchase for the Los Angeles group buy. I should admit though, that despite my zeal, I'm still quite confused myself on the whole ASU/FSO/Qtopia/2007.2 framework splits, as Jay Vaughan has pointed out a few times. To some degree, Sean's Email helped ease my confusion -- I see Openmoko like Linux Torvalds (which Michele brought up) -- Openmoko has an idea of where they want to get the phone to a basic usable state and to where we community hacker/members can start adding on top of it and making the device a household name. Openmoko has their tool of choice, but don't care what other people develop for the phone, I'm sure the same way Linux Torvalds probably doesn't care whether an end user utilizes GNOME vs KDE. And while Openmoko is working on their own framework, I have to agree with many other voices: knowing which platform to develop for, as a developer myself, is confusing. I don't like the thought of having to write multiple versions of an application that caters to GTK and Qt separately, although I recall that the FSO framework is trying to bridge that gap. But I also don't want to have to market my application as only works on 2007.2/FSO because I use GTK because that's the route I chose to build my app. I guess I personally envisioned the Neo1973 (GTA01) as the base model for developers and that the Freerunner was going to have a smoother transition into the mainstream. I agree with Sean (and several others) that the Freerunner gets them a step closer, but Openmoko still relies heavily on the feedback (and *participation*) of the community. As far as design goes, I understood Sean's Email to say that they don't care how we build what we build on the phone, and that even the design of the phone (ie: case) is open to us on all levels to make it whatever we want it to be. They're going to focus on their own framework and hardware issues, and let us do what we do best as a community. I still hold to a quote from Andy Powell on the community list, which emphasizes that we all need to pitch in where we can. I agree, not all of us have super-godlike programming skillz, and not all of us are fluent in several languages to write the wiki, but we can ALL chip in here and there if we're on the same page: If everyone put as much effort into development as they do into bitching and whining this phone would be able to cure cancer by now. - Andy Powell, May 6, 2008 Personally, I signed up to help manage the wiki to make it a better source of information. I haven't got the time to invest into kernel-level development or any hard-core programming, but I *do* have time to review a wiki page or two every single day, and will do what I can. If everybody had the same level of cooperation, this project would be radically different. At the same time, there are always going to be groups of people who are more likely to be vocal than helpful, that's why someone coined the phrase about how 10% of the people do 90% of the work. We will *always* have to deal with the same questions on the mailing list over and over and have to watch for, and manage, duplicate content on the wiki because someone doesn't know how to use a search function. That's a given. Instead of being harsh on these people and speaking negatively, here's a thought: be helpful. We're only going to alienate people if we tell people their thoughts are nonsense/worthless and RTFM n00b. I feel that Sean has just given us (or perhaps just reiterated what should have already been known), as a community, the means to empower ourselves to help on *everything* about the Openmoko project as a whole. We wanted an open platform, and it's been given to us. We're *all* part of that design. Just my $0.02... -id ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Tue, Jul 29, 2008 at 4:22 AM, Sean Moss-Pultz [EMAIL PROTECTED] wrote: [snip] Think of our products as museums. We're building the environment. I re-read Sean's post a couple of time (like a few people I am guessing :-) For some of us 'museum' may have an old/musty connotation. When I put art gallery everywhere he says museum, it landed in my my ears very differently :-) [snip] Like Will already said, by removing a manual keyboard button we are forced to self-organize using the resources in our environment. [snip] A lot of re-organizing in the real world comes with some pain .. but often, less is more in genuinely good design. This is an interesting ride ... it's good to be able to ride along. Interesting post Sean, thanks! davidv ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
