Re: multitouch possible?
Apple's multitouch system, on the software end, is based on heavy use of gestures. Gestures are stupid and limiting, so don't do them. Instead, build on simple logical rules that expand organically to multiple fingers. For example, a basic physics simulation can be used for dragging objects; one finger just pushes it from any corner, but the addition of a second finger (which holds it rigid at a point) allows that object to be stretched or rotated. Gestures aren't natural; they are based on approximations, feel detached, and always will be the boring way of doing things ;) Bye, -Dylan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA03 - buttons or touchscreen
Something that could be interesting to ponder, with regards to the combo layout, is Sony's keypad add-on. It is designed so that one can run his finger over the keys and use it as a track pad, presumably via some kind of touch sensitive surface. It's a very cool idea and could be a useful control mechanism. This way, the tracker ball thing could be implemented without taking up exra space. Bye, -Dylan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No Camera???
Think of it in terms of modularity. You do not have to carry and think about a camera which will quickly become obsolete (or is already obsolete) compared to superior cameras that are available. Phone cameras are almost uniformly terrible, because they are tacked on as extra features with really no impact on the usability of the phone. They just waste money and space producing images which could be beaten by a 2-year-old drawing with crayons. I /hate/ phone cameras, because a horrifying number of people have become convinced they can take lasting photos of important events using their telephones, and they only figure out how wrong they were when it is too late. Sure, your phone doesn't have a camera, but it does have lots of room for expandability. An external camera, actually built specifically to take decent pictures, talking to the phone wirelessly, would work much better. (Except for batteries, which is an interesting problem). Bye, -Dylan McCall On 10/6/07, Giles Jones <[EMAIL PROTECTED]> wrote: > > > On 6 Oct 2007, at 19:39, <[EMAIL PROTECTED]> wrote: > > > > > > The neo will not penetrate the consumer market without a camera. > > Not a chance. So, intentional or otherwise, the neo is going to be > > a geek's toy and nothing more. What a shame. > > It won't anyway, it's always going to be a power users toy. It's not > a "branded" device and many people buy on contract. > > > ___ > 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: Nokia "open to anything" ads
I have no problem with this, myself. The Nokia phones are fairly open - not as much as the Neo, but they are definitely free to develop for. Their N800, for example, is effectively closed only in hardware. This is no worse than a huge number of PCs, whose hardware has closed drivers. Nokia is a very succesful company with a lot of products, so they can easily spread awareness of the advantage to an open platform. That is something currently very difficult with the OpenMoko project at the moment, but essential to its success. It is nice to see Nokia taking this approach, as it shows they have a comitment to it as the powerful selling point it should be. Besides, Nokia's phones are a lot more open than various other leading smartphones -- let's hope they blast the closed ones out of the marketplace. Bye, -Dylan McCall On 10/1/07, Adam <[EMAIL PROTECTED]> wrote: > > Ad: > http://biotech9.getmyip.com/~jammy/nokia.jpg > http://img161.imageshack.us/img161/639/nokiabo2.jpg > > "Open to anything" > http://www.nseries.com/open > > I guess there are different definitions of "open." > > ___ > 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: interface design suggestions
I really like what you have done with the bar at the top. I, too, hate the gradient, and the coloured logo is a fine alternative. Excellent thinking with the keyboard, too. A lot of the other trouble has been addressed in the redesign, but you have a good eye for this stuff. I look forward to seeing you pull apart 2007.2! Bye, -Dylan McCall On 9/23/07, Dani Anon <[EMAIL PROTECTED]> wrote: > > Hi > > I was thinking on getting an openmoko when it's done and probably > developing a couple of apps but before that I think there is a big > problem with the current graphic design so I thought I'd contribute a > mockup and some thoughts. If such contributions are welcome I'd be > willing to mockup the remaining interface elements under CC free for > any usage. Note that I don't have an openmoko yet so I just took an > screenshot of the website (the one I found to be more complete > widget-wise) and remade it. You can see both here in this png I've > uploaded to imageshack: > It's work in progress, I didn't bother to do the full reflection > treatment to the icons, and the little ideograms are pretty poorly > done, a lot of other things also need to be fixed, but it's enough to > get us started: > > http://img442.imageshack.us/img442/4728/ommockupexportaf2.png > > Now some comments about the differences: > > - The current design has too many different styles all over the > interface, there are a lot of different backgrounds, styles of > buttons, sliders, etc. In my proposal there's only one background > (that gray gradient bitmap) that is used in every "input area". For > background as the "content area" I use simply white, and the only > exception is the black status area on top with the notification icons. > Using less bitmaps not only gives you a better looking design but it > simplifies development and theming, this is very important. > > - You are using non-white colors for background of the content areas, > which gives you a text contrast of 80%. This is no good, as a mobile > device is commonly used outside and visibility (contrast) is no good > to start with, so we shouldn't have anything less than 100% contrast > for variable content, i.e: black over white or white over black. > Things that the user is familiar with like symbols and titles of > programs and headers are ok not having 100% contrast since the user > already knows the captions. > > - I understand that you are using the same non-gray color through the > interface (orange) to get some coherence. This can be a good idea to > avoid making bad color choices but we can do better and get: > a) better usability. using different colors for different categories > of things is a universal and accepted way of improving usability > (think of traffic lights and signals). You shouldn't avoid this > resource. > b) better experience. The same color all over the interface can get > boring quickly! > > - Keyboard layout. You are wasting space right know, the same keyboard > can be arranged to take advantage of 100% of the width of the screen. > The new layout gives you 20% more horizontal space resulting in more > accuracy. I'm not sure at all about having backspace and enter in that > place, that particular detail is just the first thing I came up with. > > - You have a lot of padding and margin where you don't need it. As a > result of removing those unnecessary details I have saved a lot of > space. Yes, padding and margin is good wherever we have an interactive > button that would need to be pushed, to avoid errors, but we really > don't need it for non interactive items if we design properly. > > - My key buttons are now language agnostic, "del" has been replaced by > just the backspace symbol and "enter" has been replaced by the enter > symbol. The color of the buttons provide another clue about the > function. This way the same bitmaps can be used in any language > configuration. > > - (strictly design problem) I didn't like the horizontal gradient on > top, really took my attention toward the left, I felt it was a > problem. > > - The proposed layout of the keyboard is more similar to a real > keyboard, in the current design Z is right on top of S for example. > There is space at the right of L that could be used for an ntilde (Ñ) > for spanish speakers or a cedilla (Ç) for french speakers depending on > the configuration. > > - You didn't need to surround the clock on top by a border, the format > XX:XX is easily recognizable already as an independent item, and by > removing the border you can have a bigger font size that makes it easy > to read. > > - Speaking of font siz
Re: 2007.2 dialer suggestions
The biggest problem I see is that the current icons are all very similar, and in some programs we actually have two of the same icon! (The Home icon); one at top, one at bottom. For someone just learning the system, this is very hard to understand. We need more informative icons that each have their own very distinct look. At the moment, this is a very scary case of mystery meat. I think the Accept Call icon could have some indication of sound coming from the receiver, and it wouldn't hurt to have the button in the middle of the screen, where the call icon (#2) currently is located. I also agree with swapping Speaker Phone and Hang Up. A good interface needs a consistent rule for which side the positive and negative responses are on, and this must never change. (For example, Gnome's HIG). Bye, -Dylan McCall On 9/12/07, Joshua Layne <[EMAIL PROTECTED]> wrote: > > > On Wed, 12 Sep 2007 12:27:53 -0700, "Roger Borges" <[EMAIL PROTECTED]> > wrote: > > I agree with both of these points. Red and green may interfere with the > > color scheme of the phone, but maybe making the ignore/hangup icon red > and > > leaving the answer icon orange would be effective? > > While I would not suggest that we move the UI to an AngryFruitSalad > (http://catb.org/esr/jargon/html/A/angry-fruit-salad.html) - I am not > certain that a diachrome orange and black scheme is the only answer. > > However, I know the UI is themed - my biggest concern is the button > location, not the color - the color can be easily changed by re-theming. > > j. > > > ___ > 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: Yet another keypad idea
Aha! That's just like one I had dreamed up, except less bloated and very sensible. Great job actually doing it; this is very intuitive. I can see that working really well with dragging the stylus through the buttons, with no need for multiple clicks. That could lead to a sort of intuitive graphiti pad -- even moreso with a few graphics effects, where hot spots appear at positions relative to the stylus only if there is a letter in that direction. Unfortunately, you seem to draw letters in a completely different direction than I do. I can see this potentially being user configurable, where one could create his own patterns for letters. Just drag the stylus to draw an "e" as you want, and the system picks up the order in which you drag it through hot spots. I think that could really be the ultimate handwriting style input, finally accepting and building on the fact that people all draw letters differently, and that kind of stuff cannot be unlearned. This way one's keyboard is specially fit for him, which would be really unique! (Building on the "more than 9 buttons" suggestion, that user configuration could include setting the sensitivity, which would boost the number of hot spots). Great work, OJW. This is way ahead of any qwerty layout. Much more suited to a touch screen. I have some spare time tomorrow, so I will see if I can come up with an example of my own so we can compare notes. Seeing your demo here shows that it's actually a surprisingly clean thing to achieve, code wise. Bye, -Dylan McCall On 9/8/07, OJW <[EMAIL PROTECTED]> wrote: > > Just playing with another idea for text-entry: > > http://almien.co.uk/Keypad/ > > The idea is to be able to type mixed letters / numbers / symbols / > control-characters without having to look at the screen when typing. It > takes a while to pick-up, but should be easy to use once you see how it > works. > > Only implemented as a javascript demo for now, but imagine it as > finger-app > (perhaps transparently overlaid on an application). Only tested on > firefox, > sorry! > > Regards, > > OJW > > ___ > 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: The problem with touch screens
The trouble withtactile feedback via buttons is that it arbitrarily limits us in the applications that can be built. Designing a powerful and intuitive piece of software comes down to how buttons are mapped, and it often becomes horribly complicated with button combos and the like. Software using physical buttons and designed for small screens is very confusing, since there is generally not enough screen space for on-screen help. The solution tends to be a very small tactile keyboard, and, frankly, I find that even less intuitive. People can say all they want about tiny button keyboards being usable, but in my opinion, they are both ugly and slow. They also limit us in the usability of the device; A touch screen we can rotate between Portrait and Landscape mode. If there was a mini keyboard involved, that would be very difficult to design! I do not think qwerty was ever intended for thumb typing, so it is no wonder I find it so unintuitive. Far more intuitive is an on-screen keyboard using auto completion, guided graphiti, or a messag-ease inspired layout. Finally, I think a touch screen is a good choice for a platform designed to grow smoothly as a home for new ideas in mobile interface design. That isn't to say I think having a tactile keyboard, or some buttons, is a /bad/ idea, though. I don't think the hardware should get in the way of expandability, and I am driven crazy particularly when hardware makes assumptions about the software it is built for. (Eg: The Windows key). I also am strongly opposed to a device packing built in, permanent features which are less than perfect. (For example, 1.5 megapixel digital cameras). Let there be room for a portable Bluetooth keyboard; one that is designed to be a usable keyboard, rather than a tiny button pad. Okay, tactile feedback :) I agree, it's a great thing to have. I always point people to the Nintendo Wii as an example of tactile feedback done right. The input method is, itself, very tactile compared to the use of a touch screen, since it is done in three dimensions without the limitation of an artificial environment. They did a great job of making the controller come to life just with a speaker and a rumble feature -- both things we have available in the Neo. In my opinion, the additional plastic bits that can be attached to the controller (steering wheels, for example) are a disappointing departure from what the controller is capable of. The whole point is that it makes something out of nothing; it somehow feels like a baseball bat or a tennis raquet just with basic functionality that is already there. No need to buy an extra peripheral to make it become these things. It just works, like a magic trick! A random question, now: Does the Wii controller have multiple positions for rumbling? I don't believe it does, but just wondering. That, I think, would be a fantastic way to get more tactile feedback. Instead of a vibration just being an abstract concept, it could actually be focussed to a particular point. Thus, the tennis racquet would be vibrating on one particular end but not much at the base, whereas a ping-pong paddle would give a more evenly distributed effect. Back to actually practical interfaces, I think tactile feedback by rumbling can be a lot more interesting and attractive if it is not just "a rumble", but a tightening up on the top left, or on the center of the device. Have to keep in mind that the vibration has to be very slight to avoid damaging the screen. I don't think a huge ammount is necessary; just a little hint is enough for the illusion of added pressure. (After all, hands are very sensitive)... Bye, -Dylan McCall On 9/11/07, Simon <[EMAIL PROTECTED]> wrote: > > Some "screen protectors" could be made to have relief boundaries > between all the buttons... so you just stick you keyboard relief on > the screen, close your eyes and write an email! > If not then, lets forget about tactile sensations, those that look for > that can buy usb/bt keyboards! (like I'm going to do) > > Simon > > On 9/11/07, Alexey Feldgendler <[EMAIL PROTECTED]> wrote: > > http://blogs.s60.com/browser/2007/08/the_problem_with_touch_screens.html > > > > The point of the article is that touch screens lack the tactile feedback > > that's inherent to physical buttons. > > > > I wonder if it's possible to simulate some of that feedback using the > > vibrator built into Neo. > > > > > > -- > > Alexey Feldgendler <[EMAIL PROTECTED]> > > [ICQ: 115226275] http://feldgendler.livejournal.com > > > > ___ > > OpenMoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > ___ > OpenMoko
Re: Apple is going to beat all competitors
Jumping back to the iPhone discussion here... The Neo is indeed behind the iPhone in almost every tech spec except one: Openness. Do Not assume that to be useless to the average consumer! Let's take a leaf out of Microsoft's book here. I am sure most of you have seen their older advertising strategy, which pointed at the wealth of software available on Windows. In my opinion, it was pretty powerful advertising (except that it was Windows). That is what we have that no closed platform can have: A diverse selection of software, choices and ideas to suit Anyone. Anyone who has worked at a customer-service oriented computer sales position probably has noticed: People have weird wishes. Open platforms like this inspire thoughts of exploration, imagination and individuality. All powerful ideas, all difficult to achieve for software developed in single offices, in a finite number of heads tied together by contracts. In my opinion, GPS can be the killer feature here that really makes the price difference worthwhile - smaller specs or not. Look at the price of a stand-alone GPS device with maps, and also consider that those things tend to be: Ugly, closed, limited to few purposes, and (of course) independent units from cell phones - which means more batteries, more bulkiness, and more bother. I encountered somebody recently who spent close to a thousand dollars on a GPS maps system for his Palm Tungsten E, and a Europe maps pack. It stopped working within a year, and he was pretty annoyed. There are thousands of ways (both the "free beer" kind and the "free speech" kind) to get maps of the entire world, seamlessly, without forking over a penny -- and the Neo has that GPS module built right in. I tend to drool, thinking of the things we can gain from an open device that seamlessly knows where it is at any time - with that knowledge freely accessible for every application on board. Sure, there are lots of devices with built in GPS, but none of them come anywhere close to the full potential of that feature! I think the Neo can, because, as with any open / free project, there is infinite room to explore and experiment. The end user (the one who isn't a developer) needn't know that the platform can be freely developed for. What he would be interested in, however, is that the product he invests in will grow in every direction without costing him anything more. Why am I so excited about GPS? Collecting rich data, transparently, without any need for extra input form the user, is a user interface gold mine. That is why optical multitouch is so cool! All the user has to do is touch the screen, which is a single easily understood action. With that one action, the system can collect the shape of the object touching the screen, the pressure, whether the object is touching or still lifted off the surface, and the pattern on that object. With that much information, it can push out results that are completely natural, without asking for anything unnatural in return. It doesn't impose arbitrary or unrealistic limitations, and, in the example of a paint brush used on the screen, it does not rely on illusion by simulations; it interacts directly with the physical world. GPS used smoothly in a platform like OpenMoko can do that, too. -In the Scheduler, someone plans to go to a location which does not have a map downloaded. Luckily, the GPS Maps system has a little daemon running that watches for exactly that sort of thing; a message appears offering to download maps for that region when an Internet connection becomes available. -Tagging of Locations in the same interface as Contacts. Locations recognized by GPS coordinates. Synchronising locations, sharing locations (geocaching?), downloading notable locations via Maps (saving / viewing on the Maps interface?). -Known and tagged locations used by simpler tools to, for example, deactivate the phone when in some locations. -Tour guide tool; could pop up a message when near notable landmarks, as tagged by other users in an Internet service. (Those landmarks downloaded, as Locations, from that service). This is all possible, even in devices without built in GPS (just tell it where you are, or do it yourself), but what makes this cool is that it is completely transparent. The device is gathering very useful information, and it only needs the user's interaction at times when it would be completely natural. (Natural meaning the exact same communication would be required if the OpenMoko-powered device was a real person). That is cool and very possible with this infrastructure. A dream user interface is one that helps you do exactly what you tell it to do, exactly how you expect, without asking for anything extra because of its own limitations. Systems that focus on one's location in the real world are a fresh and exciting direction to go, and really inspire the excitement of exploration brought on by free software. Bye, Dylan McCa
Re: Clarify openmoko != Neo1973
Openmoko.org's front page could show more than one smartphone running the system, or screenshots of it without any hardware visible. That may magically get the point across... -Dylan McCall On 8/24/07, Daniel Spies <[EMAIL PROTECTED]> wrote: > > Dear list, > > I often read sentences like "I think I'll buy an Openmoko" in comments to > news > about Openmoko and the Neo1973. So how could we clarify what Openmoko > actually is (a Linux distribution), and what it's not (a smartphone). > > Even the commercial website of Openmoko (openmoko.com) leaves the > impression > to me of Openmoko being a smartphone instead of being a Linux distribution > *for smartphones like the Neo1973*. > > Well, at least this is my impression... > > Best regards, > Daniel > > PS: I guess all these news are from members of this list. So maybe you > could > add a sentence to all your news? Something like: > > "Openmoko is a linux distribution developed for mobile devices. The first > device it will run on is the FIC Neo1973." > > ___ > 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: Screenshots
Sorry, I feel I should elaborate, since the background already is usually light in the main content. There is already a lot of red, and blue just looks less important than red, so the colour we could use to indicate things of particular importance is already in use. On 8/22/07, Dylan McCall <[EMAIL PROTECTED]> wrote: > > Have to kind of agree with Amy about the colour scheme. I am not much of > an art person, but I am pondering a theme that rhymes with Ubuntu's Human > theme, with a more natural, (human) look to the applications. I am one of > what seems a few who has always liked the idea behind that theme :b > What I have pondered out (in way too many different mediums) is a bit > lighter than that Human theme, but I think it is helpful to have > applications behave more like people than just machines. I am not talking > about avatars that are pictures of smiling people! For example, people make > suggestions and know what they are doing, while machines just do things, > assuming the user knows everything. For a friendly interface, I think the > human behaviour can be really beneficial and unique, as opposed to the > appliance behaviour of most systems. The theme is the first place to start! > > The other thing I consider a bit problematic with the black and orange is > that it is difficult (nay, impossible!) to get a more extreme colour for > particularly important buttons and messages. For example, with a lighter > background, Red would be a lot prominent. > > Bye, > -Dylan McCall > > On 8/22/07, Amy Stephen <[EMAIL PROTECTED]> wrote: > > > > Thanks so much for sharing these pictures. I include one, and a link, on > > OpenSourceCommunity.org > > > > I watch this project very closely. It has great potential to keep choice > > available to people - even just for selecting a services provider. > > > > But, IMO, the color scheme is wrong! I know lots of amazing technical > > hurdles are being cleared and political ones, as well. But, that color > > scheme is going to hold this thing back. It should be snazzy and bright and > > colorful and full of ENERGY! Not orange and black like Halloween. The added > > gray does not help, either! > > > > All the best to you all as you work together on this extremely important > > effort! > > Amy :) > > > > On 8/22/07, Franco Austin < [EMAIL PROTECTED]> wrote: > > > > > > http://scap.linuxtogo.org/index.php?page=1 > > > > > > > > > ___ > > > OpenMoko community mailing list > > > community@lists.openmoko.org > > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > > > > > > -- > > [EMAIL PROTECTED] > > http://OpenSourceCommunity.org > > ___ > > 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: Screenshots
Have to kind of agree with Amy about the colour scheme. I am not much of an art person, but I am pondering a theme that rhymes with Ubuntu's Human theme, with a more natural, (human) look to the applications. I am one of what seems a few who has always liked the idea behind that theme :b What I have pondered out (in way too many different mediums) is a bit lighter than that Human theme, but I think it is helpful to have applications behave more like people than just machines. I am not talking about avatars that are pictures of smiling people! For example, people make suggestions and know what they are doing, while machines just do things, assuming the user knows everything. For a friendly interface, I think the human behaviour can be really beneficial and unique, as opposed to the appliance behaviour of most systems. The theme is the first place to start! The other thing I consider a bit problematic with the black and orange is that it is difficult (nay, impossible!) to get a more extreme colour for particularly important buttons and messages. For example, with a lighter background, Red would be a lot prominent. Bye, -Dylan McCall On 8/22/07, Amy Stephen <[EMAIL PROTECTED]> wrote: > > Thanks so much for sharing these pictures. I include one, and a link, on > OpenSourceCommunity.org > > I watch this project very closely. It has great potential to keep choice > available to people - even just for selecting a services provider. > > But, IMO, the color scheme is wrong! I know lots of amazing technical > hurdles are being cleared and political ones, as well. But, that color > scheme is going to hold this thing back. It should be snazzy and bright and > colorful and full of ENERGY! Not orange and black like Halloween. The added > gray does not help, either! > > All the best to you all as you work together on this extremely important > effort! > Amy :) > > On 8/22/07, Franco Austin < [EMAIL PROTECTED]> wrote: > > > > http://scap.linuxtogo.org/index.php?page=1 > > > > > > ___ > > OpenMoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > -- > [EMAIL PROTECTED] > http://OpenSourceCommunity.org > ___ > 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: Balancing simplicity with complexity
This is fantastic to read! Thank you, Sean -- and Thomas, of course. I must say, today I have had an interesting revelation of sorts... One thing that gives me a bit of trouble with the open source community is my ridiculous pickiness, and my wish to have everything smooth and unique. (Not to mention extensible and powerful). It is quite problematic since nothing ever seems to be appealing to my overly exacting standards. Today has been very interesting for me, as I have come to appreciate the work done by other people a lot more. Particularly that my favourite dream features are not the only ultimate features; that those subtle features which already exist are just as awesome as the subtle features I want to see. Maybe I just happen to have been suddenly exposed entirely to the most competently designed projects (combined with general happy vibes that are moving through the air), but for some reason I am finally able to relax under an acceptance that other people are Really Good at this stuff, and I can now resume work on my own niche without a worry about how the rest of it fits together. The air feels lighter. Bye, -Dylan McCall On 8/20/07, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote: > > Dear Community! > > A top ten complaint that we have received is directed at our user > interface. Many people feel like the current interface doesn't address > their exact needs. The organization is not "intuitive"; the colors are > not pleasing; there is no simple way to navigate "exactly" where you > want, exactly when you want. > > All Hardware has limits. All FOSS runs on hardware. Our current > interface (OM-2007) was drawn almost in it's entirety before our > designers had seen a working Neo. We had to live without an embedded > stylus in the current version. And we had to learn to adapt to the lip > on the touch screen preventing us from using interface elements on the > edge of the display -- prime real estate regions. It was tough. We > pressed on, faithful in our belief that our community would overcome > this limitation and begin exploring our new found oceans. > > Personally, I feel that one of the most important areas for this project > is the development and exploration of the mobile user interface. The > human-machine interface is the intersection of art and technology. Great > interfaces blend the visual with the technical. They balance simplicity > with complexity. Often times, I feel, really great new interfaces are > not immediately intuitive. They are not instantly natural. In fact, I > would even argue this can be detrimental to improving interface design. > If an interface is to be superior it must be different. Therefore it > can't be intuitive, that is, familiar. A better metric, perhaps, is the > learning time it takes until the interface feel's natural and intuitive. > > Now that we have freed phones, everyone can contribute to an improved > baseline interface. This is our collective challenge. Can we create > something truly different? Can we lead this incredibly important field? > > Recently, emails have been pouring in, questioning the community's > ability to make our user interface into something insanely great. While > some doubted, others stepped up. Thomas Wood, of our extended team (AKA: > OpenedHand), sent an email, entitled, "OpenMoko Design Suggestions" > proposing -- in detail -- a redesigned interface concept that was > totally finger-based, optimized for GTK+ at 285ppi and, might I add, > very cool looking. > > We went back to the drawing board with OpenedHand -- lead by their vast > experience with GTK+, Matchbox, and mobile user interfaces -- and > redesigned an incredibly promising new interface. > > Today I'm extremely excited to announce that everyone can find this, > right now, in our subversion repository, under the name OM-2007.2. We > have already converted the following applications to the new framework: > >* Dialer, >* Contacts, >* Today, >* Calculator, >* Feedreader > > You can find an official snapshot here: > > http://buildhost.openmoko.org/snapshots/2007.08/ > > The remaining applications and wiki specifications will be converted as > we approach phase 2. We have new style guidelines here: > > http://wiki.openmoko.org/wiki/GUI_Style_Guidelines > > Here's a list of the major changes we've made with respect to this new > interface: > > 1) We redesigned the user interface to better fit both the hardware > capability of the Neo and its physical form factor. > > 2) Performance was improved by streamlining the visual appearance, still > keeping it attractive, but at the same time lessening the resource > impact. The current design allows
Re: Finger Graffiti
Bah, forget graffiti! It's too difficult; the computer should be able to help you with it, but it doesn't. It essentially says "do this unnecessary work". Using graffiti is like using a help file. (And I have a pretty long rant on those somewhere). If a really clever person sat down and drew lots of pictures, he might come up with a good messag-ease-inspired input method where fingers are moved in patterns similar to real letters. Letters start being drawn from different places (or at least in different directions), so instead of graffiti, it could be like connect-the-dots. Start your letter in one point, a bunch of dots appear that you can drag your finger to, with labels for what letters those dots would lead to. For example, one dot may be labelled "I", while another could be labelled "L U". You could drag to the "I" dot and lift your finger right there to get the letter "I" (or keep dragging if more dots exist for that letter, though there wouldn't be much point). If you drag to the "L U" dot, new dots appear out of that one for the letters "L" and "U"; drag your finger to the one you want, as with "I". Graphically, there would be no static keyboard graphic; the keyboard would not obscure the screen but rather expand (smoothly) when in use. This would save screen space /and/ look cool. All the different letters could be tied into a nice little database which would contain the paths for different letters. Still no ability to lift one's finger, but since the input would be completely guided, that would not hurt like it does with graffiti! To easily look up letters, paths in the database would have to intersect, consistently, at specific points. I guess a grid (where the size of each box is recorded somewhere) would work there. Thus, each letter in the database would have a whole bunch of grid points stored in the order they must be touched. A program could generate the point that one must be moving from to reach a certain grid point for a letter. Otherwise, completely unrelated letters would pop up from points that happen to intersect with other points! (For example, I on point 0,-3 would require contact last with point 0,3). Some kind of tree would have to exist, generated by a magical program (once), using that direction information, saying what letters can be led to from other letters. That would be entirely to speed things along in the case of really big alphabets, so the computer doesn't have to look through every single letter in the database. For example, "I" at 0,-3 leads to "L" and is the end of the path for "I". Point 0,3 leads to a lot of letters; "I", "L", "J", "U", etc. (Sorry, I seem to have changed the story from that first example :p As I said, we would need someone clever to sit down and figure out the connections). Bye, -Dylan McCall On 7/30/07, David Schlesinger <[EMAIL PROTECTED]> wrote: > > >So by using fingers instead of a stylus we're not talking about the > >same use case anyway. > > That's certainly not clear to me. > > >Are you policing this project for violations? > > Not at all, that's a silly idea; as I've said, I simply _am_ obligated > to point out when a trademark held by my employer is being misused, and > that's simply a condition of having the trademark. > > My credentials aren't at issue: I've got a long-standing involvement in > the community, I've presented at both the Ottawa Linux Symposium and at > GUADEC (of which ACCESS was a sponsor) this year, I'm on the GNOME > Foundation's Advisory Board and I'm the chair of the Linux Foundation's > Mobile Working Group and vice-chair of the Linux Phone Standards Forum's > Architectural Working Group. I've been on this list pretty much since it > existed, and as Sean can confirm, I've had a long-term interest in the > project--he and I have chatted on numerous occasions, and while I'm > still waiting for _my_ unit, I can hang on a while longer... > > Let me add that there was = interest expressed by Mickey Lauer at GUADEC > week before last in using some of the "Hiker Project" components--which > we have made available under an open source license--in OpenMoko, > something I'd certainly encourage. > > Let's be clear: nobody's "violated" anything. I felt it was necessary to > give a heads-up that heading too far in the direction you seem to be > trying to stake out (i.e. "Graffiti _shouldn't_ be a trademark" or > "We're using the term in some slightly nuanced way and claiming it's a > 'different use case'") could be potentially troublesome, if the upshot > of it were
Re: GUI idea
You could try slapping something together yourself, using Glade. It's nice and easy to use, and it uses GTK, so it behaves there just like it would on the real thing. Good luck! I look forward to seeing what you have in mind.. Bye, -Dylan McCall PS: Sorry I sent this to you already, Gerald. The usual error, forgot to change the To address... On 7/24/07, Gerald A <[EMAIL PROTECTED]> wrote: I have an idea I'd like to mock up with someone who has some GUI coding know how. I could do a quick demo in flash, but I'm thinking it would probably be as quick to mock up for the actual Neo by someone who knows their way around. I figure less then an hours work, all told. It's something kind of unique, and not difficult code wise, and might help the usability. Might be better hashed out off list, and then have a demo for the list. Any takers? Gerald. ___ 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: OK, the forum is coming..
With news readers in mind, I have one wish for the forums: Really good syndication, either with RSS or Atom feeds. On 7/21/07, Adam Krikstone <[EMAIL PROTECTED]> wrote: Werner hinted at an official forums.openmoko.org. If people would just want something temporary, I could probably get an FIC or Linux subform created at http://www.howardforums.com/ (500,000 members). There are developers and network engineers that post there that can result in great threads; however, as a warning the overall userbase has become younger over the years. Regardless of age, I have not found a better user resource if you want to do anything with a phone. I'm amazed at what people can create to get around current carrier restrictions. Valerio Bruno wrote: > i'm tired to read discussion about forum is good or bad. > > i think is good: > > - can be a central point for new users (users NOT developers) > - following a thread in a forum it's a lot simpler > - it can have email notification for reply > - could be a central point for developers too! > - other motivations said by other people.. > > So i'm going to create a forum. > > Now, i can set up the forum but i'd need people who want to moderate, > and some graphics suggestions. > > Do you prefer phpBB or Invision ? personally i prefer the former. > > If anyone is doing/wants to do the same thing, please advice me (in ml > or private address); otherwise, who loves forum follows me. i'll wait > some days before start. > > Valerio, Italy > > ___ > 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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OK, the forum is coming..
I agree, a forum is a good idea! More organized and easier searched (without putting that job entirely on the user's end) than a mailing list. I prefer PHPbb, definitely. Invision is more fancy, but I am always seeing those things screw up. Bye, -Dylan McCall On 7/21/07, Valerio Bruno <[EMAIL PROTECTED]> wrote: i'm tired to read discussion about forum is good or bad. i think is good: - can be a central point for new users (users NOT developers) - following a thread in a forum it's a lot simpler - it can have email notification for reply - could be a central point for developers too! - other motivations said by other people.. So i'm going to create a forum. Now, i can set up the forum but i'd need people who want to moderate, and some graphics suggestions. Do you prefer phpBB or Invision ? personally i prefer the former. If anyone is doing/wants to do the same thing, please advice me (in ml or private address); otherwise, who loves forum follows me. i'll wait some days before start. Valerio, Italy ___ 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: projects of interest?
I am interested in a centralized locations system that replaces the address / phone numbers system, which stores actual physical locations along with GPS coordinates. Ideally, it would be encouraged that every application which could use it did use it. For example, sharing locations between people, tagging photographs with locations (both hard GPS coordinates and soft locations determined by looking up locations recorded in the database), call recieving automatically deactivated when entering a location tagged as a no phone zone, WiFi access point cataloguing / searching, navigation helpers, etc. Ideally, it would use a tagging system, of course. Locations (general areas around GPS coordinates) would be set (to names) and tagged / further detailed by the user as well as by other applications. In my opinion, it could a really neat way to integrate the real world with computers, and it could provide something similar to that "GeoCaching" phenomenon. (Which would be a really great, unique feature). I have done a few prototypes on my desktop computer (which emulates OpenMoko at record slow speed) and the results are rather promising. I have yet to bother using a database or anything that isn't dog slow, but by leaving the whole system open ended (key / value pairs added by other programs via a library) the interface ends up very tidy and easy to operate. The biggest problem seems to be setting the size of locations so it doesn't say "near my house" when inside of it. It would be handy if the phone had 720 degree laser measurement things, but that's not going to happen... Quick little random question with no relation to the above (do not let me highjack the thread with this!): Will a peripheral attached to the device that is not its own "normal" hardware be interacted with in the same way as its regular hardware? For example, would a mystical bluetooth camera peripheral be able to talk to the device and be just as useful as its built in camera, with regards to software? Bye, -Dylan McCall On 7/17/07, Torfinn Ingolfsen <[EMAIL PROTECTED]> wrote: On 7/17/07, Giles Jones <[EMAIL PROTECTED]> wrote: > We need a good use for GPS, I want something like Tomtom but this How about POI[1] tracking? Simple idea: when the Neo user enters a POI, she or he presses a button (read: starts a program), the GPS waypoint is recorded, perhaps the program asks about a name / refence for the POI, then the waypoint and other data is sent to the user's preferred server (using GPRS, SMS or whatever comms is possible) for storage. Possible uses: can be combined with Google Maps or something like that to give other people an idea of the "travel route" you have followed. When there is an OpenMoko phone with WLAN, info about any currently usable WLANs can also be sent 1) http://en.wikipedia.org/wiki/Point_of_interest -- Regards, Torfinn ___ 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: X Server MultiTouch Support
Haha! Here I am using shift religiously, at the same time saying that people don't usually press two keys at once. Fantastic. Okay, I see your point. The iPhone's touch screen is also definitely very responsive; something about it feels really good compared to the usual touch screen. Such a screen on a freed phone would certainly be a nice thing. Still, I think that most of these gestures can be achieved on a resistive touch screen. Retracting 90% of my pointless rant... perhaps multitouch gestures could be implemented (emulated) for resistive touch screens, then once a capacitive touch screen comes along the same interface could be applied except without the emulation part. I still think most of these gestures can be picked up (with some accuracy) via single touches, and having trackpad-like functionality would be fun. By the way, I have been linked to this X Server modification from four different and completely unrelated places. (I'm toying with big optical multitouch tables, too). Weird... I guess that shows how awesome it is! It would indeed be nice to see this widely used, because I'm sure that would encourage more development - perhaps even a merge with the regular x server along with a stronger effort by folks to prepare for the future. (Hopefully software will soon stop assuming particular input methods... and I want multiple drag and drop operations!) Bye, -Dylan McCall On 7/15/07, Bryce Leo <[EMAIL PROTECTED]> wrote: Yes, but you're also ignoring that capacitive touch screens are more durable and longer lasting than resistive touch screens. And I don't know if you've ever used an iPhone, but i had no problems using the multi-touch freatures one handed or with two thumbs or a thumb and index finger. Try it for 15 or 20 mins before you knock it. **Sorry for the double Dylan. Gmail stinks at handling this list. ___ 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: X Server MultiTouch Support
In my opinion, multitouch on a phone is rather pointless unless that phone's screen is big. To do it, you need to either touch the screen with two fingers at once (which is very uncomfortable if you want any kind of control), or you need both hands oriented to touch the screen (which is uncomfortable). Doing so also blocks almost the entire screen. Note that none of the iPhone commercials showcase this multitouch functionality, probably because it blocks so much of the screen and requires uncomfortable operation (often leading to one dropping the thing). Just about the only application for multitouch for a phone like this is the keyboard, and even that seems a bit odd to me since people don't usually press two keys at once. Am I missing something, like a tendency to have one's fingers on a key for a moment after pressing, while the other is being pressed? For other two-touch gestures that require specific motions, what Simon mentions is entirely possible on most single touch screens. It is possible to determine, with some accuracy, how many points are touching the screen. The point reported by the touch screen is actually the point directly between the two touch points. (This is controlled by the pressure of either touch, which can make for some pretty fancy tricks already). Now, some fancy mathematics stuff later, and you have two-fingered gestures. First finger can be assumed to not move, so when a second finger appears the position of the two can be figured out. Most multitouch gestures work with the first finger not moving anyway, so it is hardly a sacrifice. The method works pretty well, though it could be worrying bringing it out of a test scenario and into an actual released "final" product, since it's all rather imprecise. With some calibration, wide-spread testing, and some assumptions, it could be quite nice. Just detecting "gesture mode" could be a simple matter of figuring out how many touch points there are (some multitouch demos for the Nintendo DS do this really well!). With that, simple linear gestures such as the two fingered scrolling gesture could be really nice and easy (as with track pads; move both fingers vertically to scroll vertically, etc.). Touching with two fingers to do the same as a double click also springs to mind. I, for one, would be happy to see a gesture replace that scroll wheel on the left side of the interface! Bye, -Dylan McCall On 7/15/07, Simon <[EMAIL PROTECTED]> wrote: > Well I don't know what so cool about multi-touch screen on a phone unless > for scaling images and webpages. So maybe just implementing a gesture to do > that function, no need for a full blown implementation of a multi-touch > support. unless i'm not getting something... I'm not sure if it is related, but on a mac, you can hold one finger still and move the other up to down to have the screen be scrolled (like the scroll button on a mouse). And that is killer, things get relative to touches! Simon ___ 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: public access point database
"selectively geonetworking with my friends." That is a cool thought. Nay, a fantastic thought! Let's say someone finds a really cool spot in the middle of nowhere. He could pull out his OpenMoko-powered device, mark the location he is currently in (being located by GPS). When he gets home, it could be made available to his friends via some mystical but safe means. Planning becomes easy with the locations marked as efficiently as the dates. Produces a neat way to interact with people and makes a big leap connection between technology and the actual physical world, which is being pushed these days with projects like Surface. I guess I'm thinking along the lines of that GeoCaching idea (which has many fans). I think a central server is necessary only to read initial location data from, such as famous landmarks in one's region or really big wifi access points (since this is an open project that could be open for additions, of course). Would probably be wise to not download locations around the whole world if they are being downloaded instead of accessed directly on the web service... there could be the local database and the web database, with the web database accessed when possible. However, an additional service could provide that instant geonetworking idea. I suppose a central server specific to the task could do it, or email, or quiet transfer between idle devices when nearby, or all of those! An existing system like email strikes me as the most feasible for transfer over the Internet, with it being possible to use many email (or email-like) services for the same job. Perhaps that transferred data could be opened automatically following some mystical security checks by a local email program. Emails containing these locations and information could be dealt with automatically and transparently, appearing with a message explaining that some location (or schedule?) data has been sent, offering to add it to the local database. Easy to set up, too, with a trusted friends list just using email addresses and maybe some type of personal identifier for security. -Dylan McCall On 7/3/07, Ryan Prior <[EMAIL PROTECTED]> wrote: That's not as far as it goes, either -- if the software required to set up and maintain a geolocation database is free and open source, then anybody who does not trust the central provider can set up a dedicated machine with any desired level of security and privacy measures taken. There are some who would not think twice about letting their location be known to those that they list as friends -- users of Twitter and similar services come to mind immediately. At the same time - thanks to The Magic of Free Software - corporate users, journalists, and privacy-minded individuals can keep close tabs on what happens to their information. On that note, nothing stops servers running the same sort of geolocation databases from networking, either. If I host such a database on my own trusted machine in order to increase my privacy, I could still export choice data points (once per day, or upon special request, for instance) to a public database where anybody on my friends list can get at them. That way, I can carefully restrict the ability of any third party to amass information about me, while still selectively geonetworking with my friends. On 7/4/07, Nick Johnson <[EMAIL PROTECTED]> wrote: > > On 7/4/07, Ryan Prior <[EMAIL PROTECTED]> wrote: > > You seem to imply that there is a technical infeasibility that cannot > be > > overcome. If the public point database were segregated by a UNIX-style > > > permissions system and connected to via SSH, wouldn't it be just about > as > > safe as any public file server or database? Files that are "shared" > can be > > accessed, files that are private stay private. A server-side daemon > could > > negotiate friends lists, proximity, and other details without ever > exposing > > private position data publicly. > > > > Am I missing something on the privacy front? Perhaps I just didn't > grok your > > example. > > SSL would be better suited - perhaps that's what you meant. > > The main issue, I think, is that it requires users to trust this > third-party database with some very personal information - possibly up > to and including an ongoing log of their location. Even if the site > itself is trustworthy, if it were compromised it could easily be > exposed. > > The obvious solution, of course, is to simply restrict your userbase > to those that are happy with the tradeoff. > > -Nick Johnson > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: public access point database
As I wrote in that thread, I believe a static database is not the best solution. The device could scan networks while idle and associate them with GPS coordinates. A way to download existing known networks from a web service could also be presented, if one wants to have an already built catalog as you suggest (since the scanning would probably be a bit of a drain on batteries). I believe that this could all be unified with a centralized Locations system that ties real world things (friend's houses to gaseous clouds, and everything in between) with GPS coordinates. Those locations would all be given Tags and extra options for addresses and the like. (The selected tags could enable certain inputs, maybe?) For example, a theatre phone disabler service could see if you are near a known location with the tag "Theatre", or, of course, a Wifi access point finder could scan for nearby locations with the tag "WiFi Access Point". With that much data, of course, such a database could be rather hard to wield. Just pondering, though :) GPS coordinates are a really handy way for a device to know where it is, not just for the user to know where he is! The trouble is that devices really don't know the real world as well as the user; only the user knows his world well enough to know how he wants his phone to act in it. Not even the developers can anticipate the type of information he would want, or provide it all without some insanely complicated infrastructure. (Google Maps times 10). Remember, this is a small device that is there with you in the real world as you walk in it; not a big screen at home looking down at the real world from a distance. It needs unprecedented detail, and I think the best way to do that is to make it as intuitive for the user to provide his own information for that location database as it is for the system to download existing databases from the web. Bye, -Dylan McCall On 7/2/07, Don Park <[EMAIL PROTECTED]> wrote: On 7/2/07, Stuart Gray wrote: > http://www.wefi.com/ seems to be along that lines, the software they are > using seems to be windows only at the moment though :(. But maybe somebody > could write and open source one that still has access to the Google Wifi The http://www.wigle.net/ website has something closer to what you describe. Its been around for years and has an active community uploading wifi tracking logs. Its free to use and make queries from, short of downloading the entire database. Moving away from wifi for a moment, I think a personal location service would be a frequently requested app. Twitter.com could be used as a place to store lat/long records using its L: feature. Don ___ 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
Screen size vs. resolution
The Neo1973's screen, with its huge resolution (for a portable device), sounds absolutely beautiful. However, I am a bit worried about its size, as the thing is smaller across than a single screen on something like a Nintendo DS, which is hardly a big screen. Does the resolution, or the size of the device relative to the screen, make a big enough difference that this smaller screen still feels pretty big? (Or, even better, is the 2.8 inches I am reading an incorrect measurement?) Bye, Dylan McCall ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Advertising/hype
Kind of OT, but on the GPS thought... one thing it could do is map WiFi hotspots to GPS coordinates automatically as you walk / drive around. That way, for example, you could solve that problem of "not being able to easily find WiFi hotspots" (which is the big thing against WiFi right now), since you could just pull out the device and ask it where the nearest open hotspot is. (Boom! There's one). As for point of interest stuff... I don't think it would be too painful to have an address book that also has GPS coordinates for your addresses, with a little "set to current location" button that would tell the device that said coordinates are said address. (And then the addresses could have tags, such as Theatre, that the device could act on automatically). Bye, -Dylan McCall On 7/1/07, Raphaël Jacquot <[EMAIL PROTECTED]> wrote: Nick Johnson wrote: > On 7/2/07, Dean Collins <[EMAIL PROTECTED]> wrote: >> Bzzz lets not get too carried away – are the Neo's going to have te gps >> locations of every cinema globally – nope then lets get realistic >> about what >> it can and cant do. > > As someone working in GIS - getting Point Of Interest data like that > isn't as hard as you might think. The main problem would be that > you're not going to have GPS reception indoors, so you won't > neccessarially know when you're entering a cinema. :) you'd be surprised at what recent (sirfstar III) receivers can tell you. last time, I could make up the aisles in the supermarket... ___ 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: An alternative gaming top case
Someone a while ago discussed plastic screen overlays. That seems the best way to offer optional buttons, although a problem does arise if one wants to press more than one button. The other way is an expansion via bluetooth, or via one of the existing hard ports. My dream handheld would be a very basic and thin piece of hardware built to connect smoothly with a variety of devices via a big, centralized and fast hardware connector, accessing hardware available on those connected devices, offering a big screen and some kind of front-end OS... but that would be a pretty darn complicated endeavour for any time soon. Bye, -Dylan McCall On 7/1/07, Robin Paulson <[EMAIL PROTECTED]> wrote: well, i'm definitely interested in someone doing something like this - and my background is in CAD/engineering/materials with a bit of CAM, so i might as well start things off. i can't see any schematics/CAD drawings up on the wiki - can someone point me in the direction of accurate, precise drawings of the internals and the case? if not, then to sean: will FIC be releasing good engineering drawings of the component(s) or will we be going down the route of measuring hardware and drawing our own? if we are going the reverse-engineering route, is someone willing to whip out their micrometer and a decent (open-source) CAD package and make some up for us? On 7/2/07, Jeff Andros <[EMAIL PROTECTED]> wrote: > > > On 7/1/07, Robin Paulson <[EMAIL PROTECTED]> wrote: > > > > want a case made from brass with diamonds inset, and a 200mm joystick > > - go for for it. > > > The real question is, how long before we see a really good steampunk case? > anyone out there want to show off your 3D Cam skills and start putting them > up for sale... I'd buy ( rapidobject.com was previously mentioned if you > need a place to do the work) > > -- > Jeff > O|||O ___ 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: the keyboard on the competition
Perhaps someone could try building a Messag-ease keyboard that follows the growing keys scheme? http://www.exideas.com/ME/index.html MessagEase is a fantastic input method for touch screens. I've been playing with it on my DS, and after getting used to, it is far superior to a miniature qwerty! Instead of a too many tiny buttons, there are 12 (maybe more, maybe less) big buttons. You input characters by touching them and stroking in the direction of the letter you want which is on that key. It may sound a bit weird, but in action it makes sense and you can rather easily get the feel for it. The way it is organized makes fine sense. A really adventurous designer could go so far as adding a predictive text key with letters that change on the fly. (Whereas with qwerty, the layout is completely rigid). For example, if a date is being typed, the keyboard could be told (perhaps via d-bus?) to pop some numbers into the predictive text key. (Or, more adventurously, strings containing more than one character?) Combine the conventional Messag-Ease layout with the fancy scrolling effects like those used in the iPhone's keyboard (press a key, it expands), and it can be a really intuitive interface! Since the keys on a messag-ease layout can still only really be thumb sized, it is difficult to learn the layout if you keep covering up keys before they do anything, and since it is a weird layout to learn there are no hints for what to do. The solution there is that when a key is pressed, the key could expand with each letter becoming separate. When the user is making his stroke, the key that would be selected if he was to let go could be illuminated somehow. -Dylan McCall On 6/27/07, Robin Paulson <[EMAIL PROTECTED]> wrote: someone on this list had a similar idea for enlarging number keys i think, they would appear or resize depending on context iirc? http://www.apple.com/iphone/usingiphone/keyboard_large.html ___ 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: [SVHMPC] concept phone with only a touchscreen for UI
A problem with the buttons layer is that now we have something very oriented towards one specific situation, so it seems less friendly for random development of stuff, such as full-screen games without actual buttons. Of course this cover would probably be removable, but if it were to happen it would have to be /very/ removable. A great feature to support, as has been discussed here, but not one to demand. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 Update!
Samsung S3C2442/400 does 400 mHz, right? That almost beats the ancient and huge PC I am typing this on right now. (Just 50 mHz short). And if we count bluetooth, touch screen and form factor, that PC is now useless except as a file server! (Well, assuming the graphics accelerator is nice. It could be neat to operate a program like Wings3D on there). As for multitouch... unless it can be done without much added cost, I for one see little benefit. How practical is it, really, to use more than one finger on a screen of this size? It is a neat idea for gestures, but beyond that there is not much. Okay, I'll admit that my opinion would immediately change with the inclusion of multitouch, but for now there is a way to cope with not having it :) Thanks for the update! Bye, -Dylan McCall On 6/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi list, I got some news to share with you. As of Mickey's OpenMoko-talk at the Berliner LinuxTag (LinuxDay) there are some new hardware information: Phase 2 (GTA-02) will feature: -a 2D/3D-Graphics Accelerator -256MByte of Flash Memory -WiFi -updated battery: 1700mAh And the finally thing everybody has been asking for: 2 Accelerometers. F**k yeah. Looking forward to it. (Has anyone heard any updates concerning possible multi-touch-abilities of the neo yet?) Additional IRC-info I got: :) [16:14:29] ... is GTA02's gsm module now connected to the PMU, so that we have full control over the GSM? [16:14:29] Elrond: yes [16:14:29] Elrond: We can fully shutdown GSM [16:14:29] that, and we can finally measure the current [16:14:29] no more uncontrolled sucking from the battery [16:14:29] at least we know how much pwr we consume then (via [EMAIL PROTECTED]) tim/minime ___ 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: concept phone with only a touchscreen for UI
Hey, nice to see this discussion! I've wondered about this before, too :) A touch screen thimble, or a thing embedded in the end of a stylus, would allow for tactile feedback while also supporting an existing necessary feature (that is, touching a touch screen without smudging it, or at least writing accurately / naturally on a touch screen). A minor wiggle is good enough, since fingers are pretty sensitive, and it only really has to be a suggestion. Good idea, Matthew! (I may have to try this myself...) There is also the device itself vibrating, of course, which is practically a required feature for a phone anyway. The two forms of feedback could maybe be combined for an interesting effect. As for the original topic of a full touch screen UI (which I, at least one North American, love! I think those tiny keyboarded devices look ridiculous -- they're hardly tactile because they are so small)... what would be /extremely/ cool is tapping the touch screen to turn the device on, removing that pesky power button. I wonder how / if that could ever be possible? (Of course the touch screen isn't your usual button, so probably can't do it at all easily). Bye, -Dylan McCall PS: Thanks for telling me I sent this the wrong way, Jon. On 6/2/07, Jon Phillips <[EMAIL PROTECTED]> wrote: On Sat, 2007-06-02 at 13:35 -0700, Matthew S. Hamrick wrote: > Well... for a while I was thinking about implanting a strong magnet > under the skin in one of my fingers to detect alternating current. > There are a few people out there who have done this and they say they > can feel a very mild wiggle when the magnet comes near a wire carrying > AC. It might be possible to detect the current going through the > touchscreen as you make contact with it. > > But that's probably not a mainstream solution. That sounds like a stelarc solution: http://en.wikipedia.org/wiki/Stelarc What about a glove or thimble that you could put on your finger? How much does vibration tech. kill the battery on phones? Some type of current detection sounds interesting... Jon > On Jun 2, 2007, at 1:11 PM, Jon Phillips wrote: > > > Yes, it seems pretty clear that screens are the way forward rather > > than > > > > moving parts. I've seen a few solutions to the tactile feedback > > issue, > > > > with the main being have the phone vibrate slightly upon key press, > > > > along with sounds. > > > > > > Matthew (and others), have you heard of others? > > > > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ 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
