The Mobile Manifesto

Bugbyte · 05-12-2009, 09:22 AM

Note: This thread started in a different thread about making front ends easier to customize. Comments from there on the topic of the Mobile Manifesto have been moved here.

What is the Mobile Manifesto? A discussion about a possible network based future for creating a customized mobile experience. Read on for more detail.

Quote: Originally Posted by Crinos

(Sorry for not just editing my own previous post)....

A crazy ide just struck me... Would it be possible to make a frontend application with PHP?
I think it would. And with the use of HTML/CSS, the skin can be just the way you want it to be.

GPS Logger with PHP, possible
Audio/Video player/controller with PHP, possible
Audio streaming, Most defenetly possible

Phone interaction, dunno....

Think I will experiment a little with this...
As long as I can get php to talk with my IBUS controller, this could be what I want to do... Just because I can, not because it's practicall...

A system like this, could run on every possible OS that supports a webserver, php and sql. It would be scalable, since one could build new modules, and GUI can be "shipped" standard, or left to the user to custom build the GUI as they want it.

It might be a bit slower than other front end system available...

scrapp??? or a good idea?

Eureka! That's exactly what I've been thinking about, but I thought I might put this thread off topic by suggesting it.

This idea solves several problems:
1. OS dependence, which limits adoption
2. Device dependence. One could run this front end not only on a car PC but also a mobile device such as a Windows Mobile phone or iPhone. Anything with a decent browser.
3. Allowing the user to customize the GUI on a website using Flash objects they drag around and configure increases access to those without technical skills.
4. Dynamic menus and configuration are introduced. Relying on the network to load the GUI means you can update the menus once on the server and the new menus are available on ALL devices.
5. Moving some of the computing resources to the net reduces the need to take up storage with monolithic programs.
6. A net-native application has access to everything the net has to offer. All data, all computing resources.
7. Moves more into a 'mobile experience' that blurs the lines between device (car PC) and task (in-car) and real life. (Imagine the FE would switch from in car use when you arrive at home and loads a home automation control menu, or turns on the lights in your house)

Disadvantages:
1. Obviously, the downside is that when not connected to the net the user would experience interruption of service.
2. Right now, many users do not have internet data service inexpensively. However, in the next few years, that will be less and less of a problem.

I have one additional thought in this area that goes along the lines of the plug-ins. I think that Service Oriented Architectures hold a great deal of promise for delivering a mobile experience to various devices.

If one were to create a bare bones 'container application' on the mobile device (possibly a browser or perhaps more likely a java app) that effectively operates as the user interface, services could be constructed the run on the web server and function much like plug-ins. Users could configure those services to define the functionality that they would like to have.

As a simple example, the bare bones app might be able to access and relay the GPS location to the server. A service could be written that would monitor location while downloading the .csv file on Trapster.com every minute (lists the locations of radar speed traps). It would calculate when you are near a trap and send a message to the device (could be text, could be an audio file announcing the trap and location). The bare bones app would then respond the the message by displaying it or playing it.

As other, better services are added, the user would be able to access them and mix and match them to build a truly customized mobile experience.

Ummm...I guess this is a long way around of saying I really LIKE that idea.

kev000 · 05-12-2009, 10:21 AM

Quote:

1. Obviously, the downside is that when not connected to the net the user would experience interruption of service.
2. Right now, many users do not have internet data service inexpensively. However, in the next few years, that will be less and less of a problem.

Maybe I don't understand the concept correctly but, why not run the web server in the car? If the hardware/software is smart enough, it'll detect when you have connected to the car's network and maybe prompt a notice on your iphone? Then you just load up the flash/php/whatever page and do your thing.

if you have access to the net, the web services can utilize those. If not, you still can access the basic functions of your car.

The problem I see with being totally "headless" and having all the control in your smart device is the case where your wife gets in the car and she wants to do something, but left her phone somewhere and she can't find it. Also, what if your phone battery dies mid trip (shouldn't happen if you have a car charger, but heh...)? I think the idea is good, but I still think there needs to be at least a very basic system in place where you can control the system without your smart/mobile device.

For me, the optimal integration happens when the carpc system is smart enough to completely integrate with your mobile device. Bluetooth proximity detection, UPnP file shares, synchronization of gps bookmarks, etc are some of the obvious things. Then you can still use your 7" Touchscreen without having to squint at your iphones 4.3".

It should also be noted, IVI interfaces differ from the mobile interfaces found in phones and MIDs. Those interfaces are still designed with "captive attention" in mind. IVI interfaces cannot demand captive attention by nature. They are close, but the differences do matter. Thus anything that your run on your mobile device in the car will have to be designed for that purpose. You can still get away with running mobile apps in IVI environments, but it's probably not going to be optimal.

Just my two cents...

Enforcer · 05-12-2009, 11:07 AM

Bugbyte · 05-12-2009, 12:25 PM

Quote: Originally Posted by kev000

Maybe I don't understand the concept correctly but, why not run the web server in the car? If the hardware/software is smart enough, it'll detect when you have connected to the car's network and maybe prompt a notice on your iphone? Then you just load up the flash/php/whatever page and do your thing.

if you have access to the net, the web services can utilize those. If not, you still can access the basic functions of your car.

The problem I see with being totally "headless" and having all the control in your smart device is the case where your wife gets in the car and she wants to do something, but left her phone somewhere and she can't find it. Also, what if your phone battery dies mid trip (shouldn't happen if you have a car charger, but heh...)? I think the idea is good, but I still think there needs to be at least a very basic system in place where you can control the system without your smart/mobile device.

For me, the optimal integration happens when the carpc system is smart enough to completely integrate with your mobile device. Bluetooth proximity detection, UPnP file shares, synchronization of gps bookmarks, etc are some of the obvious things. Then you can still use your 7" Touchscreen without having to squint at your iphones 4.3".

It should also be noted, IVI interfaces differ from the mobile interfaces found in phones and MIDs. Those interfaces are still designed with "captive attention" in mind. IVI interfaces cannot demand captive attention by nature. They are close, but the differences do matter. Thus anything that your run on your mobile device in the car will have to be designed for that purpose. You can still get away with running mobile apps in IVI environments, but it's probably not going to be optimal.

Just my two cents...

[Edit: Sorry, I appear to have begun writing some kind of "Mobile Manifesto". I'm just in intense brainstorm mode]

Good points. Here's why I presented it that way: Until now, the focus has had to be on in-car mobile computing because that what the technology required. A PC in the car isn't usually taken with the user and if it is, it isn't used for creating some kind of mobile experience.

1. New types of hardware that are smaller, faster, cheaper connected to the web present brand new capabilities that allow one to break from the device (pc based) and location (in-car) paradigm.

2. Seamless across devices. I don't disagree at all that there should be integration between the car PC and the mobile device or that if you forget your phone that your car PC should be the substitute. I'm more interested in what that means. In other words: "What will it mean when my mobile device (car pc or handheld or whatever) has effectively continuous communication to all of the data and computing resources on the net regardless of where I am?" Or, more precisely, what CAN it mean?

When I view it from that standpoint I see setting up your PC as the web server as a necessary intermediate step (you've probably read my iPhone thread where I'm doing precisely this) to deal with a technical limitation, but not the ultimate prize. You want to keep some kind of functionality on your device for those times you're out of range of the network. However, you lose the functionality that you can get from services running on the net.

For example, think of a network service that translates spoken audio into commands. Or services that bring up points of interest based on Google searches of your location. Certainly, one can program these into your PC web server but they will need to be updated each time. If the author of the GPS tracking service adds Twitter or Facebook notification to it, you'll need to reload that service and configure and update it. That's more or less where we are today.

Instead, the vision is that as services are upgraded, the functionality is automatically added -sort of in the same way that something like gmail does when they add a feature. The difference is that users would be able to choose or substitute services as their mobile needs evolve. There is really no end to the types of services that would be available and new, unthought of services can evolve with less consideration for platform or hardware.

The mobile device (whether PC or netbook or handheld device) becomes simply a "window on your mobile experience" rather than the focus for it.

3. Reduced configuration The topic of this thread is about reducing the need for configuration of the interface. This idea is about both reducing that need but also making configuration of the mobile experience's functionality easier, thus amplifying the usefulness of the mobile experience.

One of the things main things I've observed about people who have a desktop, laptop, or car PC is that they want to customize it. Some just stick with changing the desktop background, but this community is all about hacking it and extending its functionality. I'm fairly sure the average user would like to do something similar if it was easier for them to do it -OR they would like to load up a preset range of services that someone else has put together for them (a little like the out-of-the-box capabilities of RR).

4. Overcoming the limitations of the installed base Most people don't want to install a computer in their car but they do have a phone and a decent percentage of those phones are smart phones. I'm reasonably sure that in the not too distant future that a large number of people will have a very capable mobile device, creating an installed base of potential users with a network connection. The larger that base, the more reliable the network services.

5. A convergence of capabilities that allows a new paradigm is near The real game changer is the continuous access to hundreds of millions of computers on the net and the ability to access as much data and computing power as you need. We certainly appear to be on the threshold of being able to stitch together new capabilities with far less regard for hardware or OS requirements or even data requirements than we used to. I'm reasonably confident that this will become increasingly possible in the future.

6. Open source and community development Hacking the mobile experience is something that this community is uniquely suited to do. Linux ICE, Ride Runner plug-ins and open source software like nGhost are excellent examples of how the crowd can often create something that is even more compelling than commercial offerings. Not only that, but right now, the hobbyist community is the place to do it. There's simply not yet a business model in the development of a 'mobile experience'. However, it is uniquely suited to OUR interests and completely in line with our way of development and testing. Whether an SOA is the proper technical solution is something that is, I'm sure, endlessly debatable. But that's the beauty of the community. Try something. See if it works or shows promise. Trash it. Try something different.

bes51659 · 05-12-2009, 02:42 PM

Admitting I have not really grasped all the idees that flooded the thread:-)

Dumb q's:

A Browser is all you need and then you run most of it on local host? All apps are web apps? Links take you to different functionality and web data services will provide all sort of niceaties?

I like it for many reasons already meansioned. We are definitely going towards streaming, and I already stream music from spotify at 10€ a month. Mobile web connection at another 10€/month. Definitely manageble.

But all apps has to be done from scratch then? Like getting OBDII, IBUS, DVD etc into the webserver? Plugins?

Bugbyte · 05-12-2009, 04:01 PM

Quote: Originally Posted by bes51659

Admitting I have not really grasped all the idees that flooded the thread:-)

Dumb q's:

A Browser is all you need and then you run most of it on local host? All apps are web apps? Links take you to different functionality and web data services will provide all sort of niceaties?

I like it for many reasons already meansioned. We are definitely going towards streaming, and I already stream music from spotify at 10€ a month. Mobile web connection at another 10€/month. Definitely manageble.

But all apps has to be done from scratch then? Like getting OBDII, IBUS, DVD etc into the webserver? Plugins?

The way I've been thinking of it, the services up on the web server are what provide most of the functionality. The front end app (what I think of as the 'container app') simply operates as both a conduit to send and receive messages or display/play media or GUI screens to the user. The lighter weight, the easier to run for multiple devices.

I don't think a browser with java script could provide all of the functionality that I'm thinking of, but I don't really know. Maybe a java based app would do it.

The questions you ask about OBDII and other external 'real world' interfaces are real problems that have to be solved -ones that I'm trying to think through for the iPhone project, and incidentally, ones that this community has spent a lot of time wrestling with on the PC platform. How do you interface with the real world to control relays or read OBDII data? Or XM radio? Or a touch screen input, for that matter?

The easiest way I can think of is to cheat. Use a helper computer like an inexpensive all-in-one Linux device that has a USB port and can be put on a WiFi router inside the car. Code up a way for the data to be read or sent over the USB so that messages from the handheld device can be sent to the web server and acted upon. (i.e. "Turn on the XM radio", "change the channel up", etc.).

That software doesn't exist, to my knowledge, but I've seen the idea demonstrated over here using a full blown car pc as the intermediary. Who knows? Perhaps eventually vendors will offer these devices with WiFi access. I know there are already Ethernet relay control boards out there.

I've also seen a demo of how a GUI can be built and then downloaded to an iPhone/iPod to allow custom interface to control a television switching system over your home network.

kev000 · 05-12-2009, 06:25 PM

What about storing your media in the cloud as well? Is that worth thinking about, or is that too far in the future to consider? The obvious drawbacks are the fact that people normally seem to have local copies of their music on the device itself, as well as on their home pc. The other drawback again would be dependence on the cloud: no cloud no music. That would kinda suck.

To me this could be the best of both worlds:

I'm going to try to implement some of these ideas into nghost3. For instance, everything is run as a plugin in nghost3 with an IPC interface to other plugins. Why not make some of those data critical plugins daemons and separate them from the UI. That way, the car can run in "powersave" mode and not power any GUI. Meanwhile, your data is still accessible from the net.

I'm a huge fan of wcf c# web services. Hooking up to the nghost3 ipc via c# is trivial and getting the data to the web is also trivial.

Even if the net side is never done (but any volunteers to help would be appreciated

), building the capability so it can be done isn't a bad idea. Thanks bugbyte.

Bugbyte · 05-12-2009, 07:03 PM

Quote: Originally Posted by kev000

What about storing your media in the cloud as well? Is that worth thinking about, or is that too far in the future to consider? The obvious drawbacks are the fact that people normally seem to have local copies of their music on the device itself, as well as on their home pc. The other drawback again would be dependence on the cloud: no cloud no music. That would kinda suck.

Absolutely, 100%. I think there are ways around these issues, though. Like, if you select a song on a playlist, if it is on your device from a previous use, it plays while the next song on the playlist downloads at the same time. Sort of anticipatory downloading.

For example, I can currently access all of my song that reside on my home computer via my iPhone and play them. But it isn't perfect because if the connection lags, the playback drops out, the song pauses and never resumes. I'd rather it download and play. I'm sure we can come up with better solutions.

Crinos · 05-13-2009, 03:30 AM

Quote: Originally Posted by Bugbyte

Ummm...I guess this is a long way around of saying I really LIKE that idea.

Perhaps I should get to it then?

Bugbyte · 05-13-2009, 09:19 AM

Help me out here, a little as I'm not a developer. IPC is inter-process communication, right? So, if you had two processes like an audio playback daemon and an OBDII daemon, the OBDII daemon could tell the audio daemon to turn the volume up a little bit when the car goes over a certain speed?

And, IF you had a continuous network connection you could access, say, a GPS daemon and poll the car's location every now and then from anywhere in the world. That would include giving a program (such as a service running on a server) the ability to do the same?

minicoopS007 · 05-14-2009, 04:45 PM

Bugbyte, this is where you need to examine various message patterns to handle large messages and streaming and communication patterns. For different applications we may need duplex collaboration where messages can be initiated from both directions. Other applications may follow a request/response. For applications that are not to tightly coupled you can pull the trigger and forget, i.e. send the message and forget.

kev000 · 05-14-2009, 09:29 PM

Quote: Originally Posted by Bugbyte

Help me out here, a little as I'm not a developer. IPC is inter-process communication, right? So, if you had two processes like an audio playback daemon and an OBDII daemon, the OBDII daemon could tell the audio daemon to turn the volume up a little bit when the car goes over a certain speed?

And, IF you had a continuous network connection you could access, say, a GPS daemon and poll the car's location every now and then from anywhere in the world. That would include giving a program (such as a service running on a server) the ability to do the same?

Exactly

Right now, I think carpal implements an IPC design along with nGhost2. I think others should also because it's a very scalable design IMHO, but that is up to them...

malcom2073 · 05-14-2009, 10:00 PM

CarPal currently does implement an IPC message system. It would be extremely easy to write a plugin (as carpal is very plugin based) to add a tcp/ip frontend for the IPC allowing network commands from say, an iPhone to your car.

I'm working on this even now, to provide more seamless integration between my carpc and home network, eg allowing my homepc to send things like "rescan media" or "mute volume" commands to the carpc.

As for the GPS idea, there is an idea in the works for something like this, a sort of "where are my friends" sort of dealio.

User Name		Remember Me?
Password