On Thu, Sep 16, 2010 at 1:15 PM, Jeremiah Foster <
[email protected]> wrote:

> On Thu, Sep 16, 2010 at 1:02 AM, Skarpness, Mark <[email protected]
> > wrote:
>
>> Yes, that's exactly what we expect.  One version for every MeeGo compliant
>> device.  Device-specific tailoring will be the exception - it's expensive,
>> time consuming, and results in an app that will run on fewer devices.
>>
>
> This certainly makes sense from a developer/vendor standpoint.
> Unfortunately, I'm not so sure about the user angle as they don't care if an
> app works on OTHER devices than their own.
>
>
> I disagree. Users want to move their photos easily from their phone to
> their TV, move their phone calls from the phone to the car, etc.
>

That I believe still falls under "their own devices" :) What I was saying is
that an N8 owner doesn't care much if an Epic Citadel type of thing runs on
a C7 or not (let's pretend for a moment that those two are MeeGo devices).
If compliance means forcing developers to go for a single lowest common
denominator version of the MeeGo APIs, you will never see cool stuff on
MeeGo once the first wave of devices passes (and that's something high-end
device users DO care about).


>
> The Symbian experience so far is suggesting that quite a few developers
> believe that having generic apps able to run on a hundred different devices
> are a dubious match for apps tailored to maximize user experience on a small
> number of bestseller devices.
>
>
> If you have _one_ OS  with _one_ well defined API, you will gain a great
> deal from a developers standpoint.
>
>
With the various UXes it already is failing on that promise, but that is not
the point.

The problem is that it's a black and white setup with a conflict of
interest. You want developers to only use your API (so make it as
all-encompassing as possible), but also have the need to make this API as
small as possible due to financial/technical constraints. For example, MeeGo
currently has no gaming or social networking oriented APIs, which are a must
have category on many of its device categories. Existing Linux libs/apps
*can* mitigate this if done properly. The only trick is to make the
compatibility/compliancy thing a CONTAINS relation, and make proper, clear
names for them, so that whatever compatibility level you are aiming at, you
know exactly what is beneath that - MeeGo Core, UX, Extras, Surrounds,
etc...

Best regards,
Attila
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev

Reply via email to