Windows Mobile 6: Getting Started


I'm currently worried about the rather unapproachable nature of our Windows Mobile documentation. At times it seems to be like a smooth sphere, with no entry points. Once you get inside, and know what's going on, you can muddle through OK. But how can you get inside?


To that end, I'm trying to remember what it's like to be completely new to Windows Mobile. Rather than taking the approach of a sharp blow to the head, I've asked around, and tried to come up with some slightly more user-friendly (that's a word you don't hear much these days) introductions to getting started with developing with out platform.


I've love to hear your opinon on these 'portal pages'. Imagine they are at the highest level in the docs - when you are looking around for entry level stuff on developing, this is what you see. They'll link to existing topics, or new ones if nothing suitable exists.


 What important entry-level stuff are we missing? Both missing in terms of not actually documenting, and in terms of leaving out from these sample "roadmaps". What did YOU need when you were getting started? 


 Option 1



Option 2



Option 3



 


 


Comments (5)

  1. JohnGalt says:

    I'd be more worried about the fact that programs devleoped on Windows mobile look HORRIBLE.

    Something has to be done about it, or the iPhone is going to kill of Windows Mobile completely.

    Silverlight isn't enough on the Mobile. It needs to have full integration with data base engines for this to work, and we have be able to provide amazing looking graphics. This means that the devices need WAY more ram, and should have their applications dumped out into 2 or 4 gig onboard memory instead of shared with the ram on the machines. Then we'd have a chance...

  2. MSDN Archive says:

    Way to hijack the thread! Can you hijack a thread when you have the first comment? 😉

    Good points though. Windows Mobile apps tend to look like Windows95 apps, don't they? We could definitely do with some snazzier UI controls, and some more innovative input techniques.

    Windows Mobile 6 has a port of the Tablet Ink APIs, which might help, but there is still not a lot more than the same old buttons, menus, drop down lists and so on.

    Now, personally (warning: my opinions are not those of the company etc etc), I'm not a fan of the Win95 look, as I think a phone is a phone, and a desktop computer is a desktop computer. Why does a phone need a Start button? But I'm guessing here that the goal was to simplify porting desktop apps, and provide a familiar environment.

    Remember, the current phones have evolved from the Palmsize PCs and Handheld PCs. And while that would have been a good time to invent an entirely new UI paradigm for mobile computing, leveraging the Win32 APIs, MFC and familiar controls and dev tools was a good way to enter the market.

    These days I think phones are obviously capable of being defined as devices in their own right, and we need to think of developing controls that are designed for phones - controls that work with fingers, that work when you are on the bus, or when you are walking around trying to get an address in a hurry. Controls that look COOLER than the iPhone, dammit 🙂

    Of course there's nothing to stop you writing your own library of these controls...

    Does anyone know of anything cool out there that we can all use in our own applications?

  3. JohnGalt says:

    We're in the process of doing exactly that. Writing our own controls and taking over the entire interface for our mobile version of our software.

    But man, what a pain in the neck. I wish there was a good control set out there like Dev Express or something....

    Right now I've only seen two control suites and both of them look like Windows 3.1 (which is what Windows mobile looks like, Windows 95 is a step up from what it currently looks like)

    The key is to forget the metaphore that works on a computer. It doesn't work on a phone. It's about what you want to do, not how to look for information.  

    I want to call someone. I want to schedule a task, I want to book an appointment.  This is what I want to do. I don't want to look at information, I don't care about files because that's not the point. There shouldn't even be a file explorer or an exposed file system.  This is what the iPhone understands.  

    ACT don't organize.  Present information intelligently as the user tries to ACT.  This is contextual searching at it's finest.

    I don't need to see how many appointments or tasks I have. I need to be notified of new tasks due.  When I hit the task button I need a list of due tasks and a section to add another one on the same screen.

    Yes, part of what needs to be done is event management, but that's a very small part and is a notification thing, not a listing thing.

    BTW, it wasn' a hijack. The point is very valid about what you're talking about.  Developers don't want to develop for 1990 interfaces when they've seen 2007 stuff.  MS needs to drop everything else and get WPF native with data base and WCF embedded directly on the Mobile devices yesterday and reengineer (i.e. steal whatever you can from the iPhone) the interface, and give developers an up-to-date toolset that has an up-to-date interface.

    By doing so, we can drop all of the rest of the crap, and make developing on the Mobile platform very easy.

    Until that happens, MS is poised to lose everything they've gained in the mobile market and become irrelivent. No matter what development tools are provided.

  4. Mike Edwards says:

    "I want to call someone. I want to schedule a task, I want to book an appointment.  This is what I want to do. I don't want to look at information, I don't care about files because that's not the point. There shouldn't even be a file explorer or an exposed file system.  This is what the iPhone understands."

    That's not a new thing by any means - it's the whole cornerstone behind the development of Palm OS way back whenever that was. Concentrate on the job required, don't require users to know about files, file systems etc.

    The problem with writing your own controls is that your app stands out, and not necessarily for the right reasons - people using a WM device get used to the way that WM works, what interface controls do what, how to use them, then your app doesn't conform to the way that everything else works on the device, so people consider it difficult to use. I've developed (at a fairly basic level, I admit) on Palm, Windows Mobile and Symbian devices, and one basic rule with all of these is to make sure your app uses the platform interface so it looks as if it could be part of the device.

    I'm not saying it couldn't be improved - let's face it, WM hasn't changed much in appearance since Pocket PC 2000 - but I don't know if I'd want to encourage people to develop apps that look very different to the underlying platform (except in kiosk devices, of course).

    To the original point, my problem is finding different information to (possibly) explain an issue in a different way if the initial stuff isn't clear. It's easy to go off down a series of links in the MSDN docs web site and (a) find no way back, and (b) keep getting directed to the same information over and over despite the source link being different.

  5. MSDN Archive says:

    Thanks Mike. I think I'm hearing "Help us make apps that add to the phone experience"...?

Skip to main content