There have been many starts made on Mac front ends, with few completed projects or even distributable code, however buggy or crude to install the project might be. Why?
I think there are two reasons: (1) there are no good examples of driving media apps to provide inspiration, including those available for PCs; (2) Neither the iPod, desktop apps nor Front Row provide metaphors that fit use while driving. The result is that very elaborate projects get prototyped, or features that make little sense in a car are developed, and the projects fizzle out as the programmer gets bogged down in features that don't really add value. That's not to say that those who've started Mac front ends aren't up to the task. But the first good front end app will need to have simple design principles that fit use by a driver, and keeping it simple takes a good metaphor and iron discipline.
Before developing a Mac car-media app, first decide the role you want the Mac to play, and code appropriately.
1. The Mac may just control its own functions, and provide no enhancements to the car's radio. It can be connected simply via an AUX input jack on the radio.
2. The Mac could control the car's radio and amp, especially if the radio is bus-controlled. The Mac would be connected to the Aux input and the bus. The bus connection requires a USB interface. An infrared remote may be an alternatve instead of connecting to the bus.
3. The Mac could supplant the car's radio and amp, and provide all of the media for the car. The Mac would be connected to the speakers, and would likely need its own amp. Forget the RadioShark and other tuners designed for use in a house -- their reception will always be poor in a moving car. The HQCT is a serial-controlled radio that can provide AM/FM if your car has an amplified antenna. Both XM and Sirius satellite radios have serial-controlled products.
Next: what belongs in the software.
You know, it's really easy to design, on paper, what is in your own opinion an ideal Mac in-car front-end. Bringing it to fruition is an entirely different thing. Anyone in the world can go around criticizing things, so perhaps it is time to put your money where your mouth is. Go code this front-end you have scribbled on a piece of paper!
-
Well, as far as I can tell from years of experience, proper design is the most difficult and important part of any software. Why do you think the analysts and architects are paid few times of what the coders are getting? Any trained monkey can code.
-1Originally Posted by Jirka Jirout
-
Not every program that can run on a Mac (which now includes Windows in a -ahem- window) makes sense when driving. Even some apps that could be helpful just don't fit, or just aren't really very good. Here are some things to leave out when building a professional car media app for the Mac. Hobbyists can and will ignore this advice.
1. Navigation. The navigation apps for the PC are not nearly as good as the standalone or built-in systems. Even the one decent app for the PC is quirky, to say the least. And the Mac nav apps are not ready for everyday use. It's a shame, because the destination input interfaces on nav devices are clumsy.
2. Speech recognition. Most car interiors are noisy, which confuses SR systems. That's why this feature only shows up on super-luxury cars that have very quiet cabins. Even then, unless they are designed to remove the sound of the stereo from the input stream, they won't work well.
3. Text that's smaller on the car's display than the thickness of your finger. Any smaller and it either takes too long to read or is likely to be misread. (But your eyesight is so great you can read text half that size? It's not about you, once your front end goes out to the public.) Also, eliminate any text that describes what an interface element is, like "Song Title" or file path or the like. If it's not obvious, crowding more text onto the screen is not a solution. Likewise, leave out any text about the app.
4. Skins. Do I hear gasps? Skins are the most-requested feature, but this is advice for a professional-grade app as opposed to DIY kits. You won't be able to include others' copyrighted logos or photos in your app, so skins are just for visual gimmicks that will make the app harder to use. If anything, provide a way to alter the color scheme.
5. Scroll bars, sliders, drop-down menus. Like text that's too small, any control that requires you to watch the screen to accurately use it is bad. (HOWEVER, if a few controls are placed along the edge of the screen, so they can be located by feel, that's fine.)
I won't offer advice on what to put in to a car media app, in case I decide to take up aychamo's challenge to code rather than just criticise. (If I do, I'll actually do realistic testing in a car while driving. Not like some folks.)
Next, what to charge for it...
Note: This is not meant to be inflammatory.
You really should take up programming. The problem is that your advice comes across as though you think your idea of a front-end is the end-all and only way a front-end should be made. It isn't. It's just your ideas. And they are, at best, just that: ideas. Anyone can sit around and say what would be, in their opinion, nice in a front-end. But to actually make it is an entirely different story. If you are so strong in your convictions it honestly may be worth learning to program. Otherwise, I just don't really see the point.
-
The point is to get some independent view. View of someone whose thinking is not affected and limited by working in particular programming environment or by being associated with a particular existing product.
Although I may not agree 100% with some of mini's points, input from someone who is just thinking on very general level is very valuable.
+1
-
Do you need to charge for your app?
No, if it's a hobby/learning experience to build your own CarPC, or you're just interested in being known in MP3car as someone with a CarPC front end. Be realistic; if that's what drives you, don't charge someone else for your experiences.
Yes, if the goal is to provide an excellent car media app. There are three reasons to charge for it (four if you think it's so good you'll make a living off of the product).
1. It puts customers in charge. When people have to pay for it, they'll demand that the installation works for everyone, every time, on every Mac. And that's just one demand -- they'll expect to download it simply, to be able to use it without any special expertise or knowledge of screen size, how the app is built or where files are stored.
Frank Lloyd Wright said, "Limitations are an architect's best friend."
Seemingly mundane demands of users can drive you to come up with solutions that are elegant rather than gimmicky, or impractical for use while driving on a busy freeway, or that are work-arounds.
2. Quality costs money. Getting people on MP3Car.com forums to try out your software isn't sufficient for testing, because they aren't typical Mac users, nor are they typical drivers. They're the cutting edge, not the broad cross section. Likewise, beta-testing isn't the same thing as quality control testing, it's pre-release marketing.
En Vogue sang, "Free your mind, the rest will follow."
Quality requires testing by people who don't know work-arounds and troubleshooting techniques, and who aren't prepped with what to avoid. People who THINK DIFFERENT(ly) than you do. But the feedback will open your eyes to what really works.
Quality requires time, careful design, and a development plan that includes rolling fixes and improvements into the product, then re-testing. You may need to provide the Macs and the connecting devices, and to pay your testers. So you'll need to charge to recoup those costs.
And quality is the only way to control product-support costs.
3. So others can sell it. A good car media app should be sold through resellers, at least those who sell the hardware the app needs. They won't bundle it if it there's no value versus getting it separately, nor will they include it if there is no company behind it to handle support and complaints.
Randy Newman sang, "It's money that matters..."
If you can't show them the money, you're wasting your time. And having their help in spreading the word about the app will be a major boost to your marketing.
So what should you charge for the app? Turn the question around: If the app's not worth $20, why build it? It would wholesale for $8 to $10, and be licensed for bundling for $1 to $2.
From there, the breadth and elegance of the features can get you a higher price, which then affects the wholesale and licensing prices proportionately. Demo versions and trial licenses aren't price drivers, they're marketing tools. The ultimate pricing question remains the same.
Previously I wrote that there are three approaches to providing car media, but I'm changing the order to fit their pricing models, and giving them nicknames:
1. MacPod. Mac is an auxiliary playback source, like a bigger iPod with it's own in-car user interface. That's the baseline app, so make it worth at least $20.
2. MacRadio. Mac replaces all of the stereo functions of the car, when used with serially-controlled radio. $20 to $40.
3. MacStereo. Mac provides a user interface for all of the built-in stereo components in the car, using a bus interface or IR blaster. This is actually the most complex to build, because each bus interface and radio requires slightly different software. $40 to $60.
The two are not mutually exclusive. Not including Apps that come with OSX (Terminal, Mail, and iCal) which I could be considered as paying for, I use free ware products (Firefox, XCode, Eclipse, and AdiumX). Trying to argue that these aren't professional and quality applications is not one I would advise taking up with their user base
The big piece is dedication and availability. If a single person is writing a large App (a car frontend for example), they will get side tracked by the rest of life and this effects quality, eta, feature set, or some combination.
Money is a way to combat this, but realistically no one is going to get rich off a Mac car front end (the user base just isn't there).
The other way is Open Source projects with a core group that can keep it on track and moving forward.
This is not always a good thing (and in many cases it's a bad thing). Striking a balance between what the user wants, when they want it, and reality is no small task in and of itself.1. It puts customers in charge.
In a closed source free project, the control is in the developers hands. The user has the choice to not use the software, in which case there is no impact to the developer.
In an open source project, as long as the request fits in with the overall view of the project, it is more likely to get it (and the user has the potential to have it added themselves (either doing it them self or finding someone to join the project and do it). Again the user can decide to walk away, but still there is no real impact to the developer.
In a closed source paid for product, the typical user (especially if they are communicating directly with the development team) feels like they should have a say in the direction of the product. In this case (for a small scale product) it is much more critical to the developer if the customer walks away (e.g. direct loss of future income as well as poor reviews (justified or not) that will keep other potential users away).
That's not to say that customer input isn't very valuable, especially in the early design and planning stages (where it is really a requirement), but it is by no means a benefit to being paid for an application.
The average Architect and Developer are far more familiar with the limitations of a project than a user. The average user is also unable to understand most limitations (just look at all the continued requests for GPS mapping in a frontend. Nice idea, but not really practical yet).Frank Lloyd Wright said, "Limitations are an architect's best friend."
You sort of touched on it with your "think differently" comment, but you don't need what you described above. You need people that will document everything they did from the install until a problem was encountered. I don't care how good you are at finding bugs if all you can tell me is "I don't know, I just clicked the button", then 90% of the time you are worthless to me as a programmer.2. Quality costs money....
Quality requires testing by people who don't know work-arounds and troubleshooting techniques, and who aren't prepped with what to avoid.
A good QA person needs to understand the product and understand how it is supposed to work, but be free thinking enough to do things in an unexpected way.
The two have nothing to do with one another.3. So others can sell it.
Linux doesn't cost you a dime, but RedHat makes a bunch of money reselling it.
What matters for someone wanting to resell it are:
1) Is it easy to install/update.
2) Is it simple enough that I won't have to support simple questions (e.g. "How do I play a song?").
3) Is there a method for the user or myself to get support for indepth problems?
4) (the big one) Can I make money off of offering it?
Furthermore, if you start seeing shops offering Car PCs it will be Windows for some time to come. It's the same story in the car that it is in the rest of the computing world, people will stay with what they know and what they (being the user) perceive as being easiest for them (I still get people asking how hard it is to transfer files between Windows and Mac...).
I also don't see a big market for professionally done Car PCs at this time. The LCD alone typically requires a lot of custom work, most people aren't going to be willing to spend somewhere around a grand just for an LCD (assuming a cheap one, not a daylight readable one) and it's installation before you add in AMPs, the computer, etc.. And the "average" (if there is such a thing) person dropping the kind of money on their car to install a computer by a shop is not going to be happy with the in-dash retractable model LCDs (at that point they'll just go with the Alpine, Eclipse, Pioneer, etc.. units).
So ~$700+ (Mini = $600, P1900 = $100, plus an AUX input) assuming no LCD vs $200 - $500 for a kit or after market HU that will just let you use an iPod? You aren't going to get many/any takers here.1. MacPod. Mac is an auxiliary playback source, like a bigger iPod with it's own in-car user interface. That's the baseline app, so make it worth at least $20.
For the same reasons as above, I see no market here.2. MacRadio. Mac replaces all of the stereo functions of the car, when used with serially-controlled radio. $20 to $40.
It better A) have a lot of nice features, B) be really slick and easy, and C) sell a lot of copies to justify that kind of price.3. MacStereo. Mac provides a user interface for all of the built-in stereo components in the car, using a bus interface or IR blaster. This is actually the most complex to build, because each bus interface and radio requires slightly different software. $40 to $60.
A and C might appear to be mutually exclusive, so let me explain. For a Mac user there are decently usable alternatives (iTunes, FrontRow, individual Apps) that might not be ideal, but are perfectly usable when compared to an App you have to pay for that offers little or nothing over them (this is point A). Alternatively, to generate an App that will make someone want to spend money on it is actually worth more money than a user is going to be willing to pay for (use a base of $50/hour and figure a couple of hundred hours to over 1000 when all is said and done). So to bring the cost down to something the user will pay, but allows you to pay your development costs, you need to sell a lot of copies (point C).
For a small time operation developing an Application that will not be making/saving it's users any money (e.q. Point of Sale terminal, inventory system, money manager, etc..) I think you are better off releasing the core application as free ware then:
1) Charge for support (assuming that you have reasonable documentation that users can help themselves).
2) Setup for project donations.
3) Build your architecture to support a plugin model, then sell the plugins (but still have a usable core App without them).
Hopefully I didn't come off as trying to crush your ideasJust trying to share my experience and observations about how software development seems to be going.
-dave
Posting Permissions
LinkBack URL
About LinkBacks
Reply With Quote
Bookmarks