This week, I'm going to branch off a bit and talk about the Microsoft Macintosh Business Unit, aka, the Mac BU, and specifically, some of the things I'd like to see from them.
Now, not everything on this list is a ''must have''. I also realize that with the current size of the Mac BU, they can't do all of this. But, I would like to put it out there for people who have large numbers of Macs and accounts with Microsoft, so when Microsoft gets requests for items on this list -- or for other things I haven't thought of -- they can back up those requests with statements like, ''This would affect x Macs and y dollars''.
As the folks I know in the MacBU have said for years, if there's a business case for something, the answer can become 'yes'' much more easily.
There's also no way people working in the Mac BU can do all of this themselves, not without becoming the biggest division in Microsoft. But I would like to see them partner with other divisions in the company, so they could share their experience with and understanding of the Mac platform. This would help avoid debacles like the (none too soon) retired Windows Media Player for Macintosh.
But don't restrict this partnering to just within Microsoft. There are a lot of people out there who have done a lot of work that could, if the Mac BU partnered with them, help Microsoft create a lot of great new products for the Mac without having to do all the work themselves.
I'm not going to go into specific features of Office 12. That would take weeks. Literally.
As an overall package, I think compatibility beyond just the basic file formats needs to be handled better than in the past. There's far more retraining needed than there should be when moving someone between Office on Windows and Office on the Mac. Outside of operating system conventions, the UIs are just too dissimilar. People need to realize that the days of ''Well, Mac users are primarily home users'' are done and gone. If it is at all possible, the UIs for the two versions must track as closely as can be done within the respective platforms. That means replicating the new ''Ribbon'' UI for Word as closely as possible. No, it may not be Mac-like, but the ability to move smoothly between the two platforms is critical for many users.
The fact is, Office has to exist in two worlds, and it has to do so smoothly. Unlike Photoshop and the CS Suite, the Windows version is always going to be the favored child at Microsoft, so the Mac version has to deal with that.
The goal here should be the absolute minimum of retraining costs. I know it would make my life much, much simpler.
It works both ways too. Just try to do a ''Forward as attachment'' in Outlook. I'm beginning to think it can't be done. But in Entourage, it's right in the context menu for a message, or in the Message menu.
This can indeed work both ways. Outlook is in desperate need of UI simplification.
While I'm sure the Mac BU folks could do this themselves, they don't have to. Mark/Space's Missing Sync for Windows Mobilehas most of the basics down now. What they really need is just some minor things, like more transparent backup, better Entourage synchronization, and the ability to sync directly with Exchange from a Mac while docked. I think we also could add direct iSync and tethering support for Windows Mobile Devices, installation of .exe files, and a rework of the Bluetooth sync, which is pretty weak right now.
If the Mac BU worked with Mark/Space and the ActiveSync team to help Missing Sync climb those last few steps, everyone would win. Microsoft would have another market for Windows Mobile device users that ''just works'', Missing Sync would have a much better product, and neither would have to do all the work themselves. A better sync option for Mac users and Window Mobile would drop support costs and make handheld decisions much easier for everyone.
Obviously, the Mac BU isn't going to port DirectX to the Mac, and create a way to keep it in sync with the main version on their own. That's a ton of work. But again, by partnering with the DirectX team, they could help them do this the right way. The Mac games market is small for two reasons, namely the number of Mac users. But more importantly, if you use DirectX, you have to completely reinvent all that work to get that same program on the Mac, and even then the features may not translate.
The Mac game community is starvingfor product. I know I'm just one person, but I've handed out three complete copies of Neverwinter Nights and the two expansion packs as gifts. They were paid for, not stolen.
The licensing of DirectX to the Mac would be a money maker. It would give the game developers a way to sell to the Mac community, (Ask Atari about the constant call for a Mac version of Neverwinter Nights 2 if you doubt there's interest), without it requiring significant differences in the code bases. It's not like you'd suddenly have half the Windows gaming market dump Windows for Mac OS X or anything silly like that. But there's a few million Mac users, including yours truly, who would buy more games if they could get the games they want. Microsoft makes money off of licensing fees for the libraries; the ISVs make money from more sales, and the hate mail levels would go down. Win, win, win.
Read on to see what Welch has to say about or Mono, Flip4Mac and Remote Desktop client improvements.
It may not seem like the game community has much to do with the enterprise, but if you look at the main drivers for superior GPU technology that makes all applications look and behave better, it's the gamers you need to thank. You like having a better UI, or a prettier one? Well, you need the graphics muscle to push that. And gamers drive this more than anyone.
Microsoft supporting Mono directly and enthusiastically is such a no-brainer that I'm really shocked that it still hasn't happened.
Mono is far and away a better .Net implementation for non-Windows platforms than Microsoft's Rotor project. But there's only so far it can go without Microsoft's direct help.
This is one that I think would directly benefit the Mac BU, as .Net and Office go together quite well. It also would be great PR for Microsoft -- a way to really extend the benefits of .Net, and give Microsoft a footing in places where they wouldn't have a chance without a huge fight.
In addition, the Mono project has done so much excellent work on its own, that Microsoft wouldn't have to do all the heavy lifting. There's Mono for OS X on PPC, Solaris, Linux, even Linux on S390. There's work being done to bring Mono up on OS X on Intel.
This is not a part-time thing done in some undocumented, spaghetti-code, only-works-with-constant-handholding manner, but a serious project run by grownups. It's too brilliant for Microsoft to ignore, and I think the Mac BU, since they have more practical Unix coding experience than the rest of Microsoft's divisions, could not only do a good job facilitating support for Mono, but directly benefit from it as well.
In the enterprise, the ability to easily have .Net as an option without dealing with platform limitations would make life a lot easier there, as well. People may not like Microsoft, but .Net is a solid, mature platform for business applications, and it's almost dumb that Microsoft isn't working with Mono in an official way to get it on every platform possible.
Work more with Flip4Mac for better WM Codec Support
Windows Media Player for Macintosh is dead. Long live Flip4Mac!
Seriously, while we don't know the extent of the partnership between Flip4Mac and Microsoft, (although if either party wants to talk to me about it, I'm all ears), supporting Windows Media as a codec for Quicktime Player on the Mac is a much better implementation than we've seen to date. It's not perfect, and, in fact, there are things I still prefer Windows Media Player for. But overall, Flip4Mac provides a far better user experience for Mac users, (Scrubbing finallyworks!) than Windows Media ever did.
But right now, all you have is a better UI for the same restrictions you had in Windows Media Player for the Mac. So why stop there? Work with Flip4Mac to provide support for Windows Media 10, and the upcoming Windows Media 11. Sure, it may never get on the iPod, but so what? It would make a lot of people, like Napster and Yahoo, happy, since they can't, with the current Windows Media limitations, get into the Mac market at all. It also would make the other MP3 player people happy since they'd have new markets.
Do I think it would hurt the iPod's dominance? Not even close. The iPod dominates for reasons that have nothing to do with silliness like DRM and file format. The iPod and iTunes are just the results of foresight and near-perfect implementation. File format is irrelevant to that.
It also would help out organizations like CNN, VH1 and MTV, which are using Windows Media, yet not able to serve the most multimedia-aware customers in the computer market -- Mac users. For companies that want to start using things like videoconferencing and streaming video more, it would let them pick the best product for their needs without having to worry as much about who can use it.
Create and Publish a Public API for Entourage's database and create a plugin API for Entourage
This is a request that I've heard a lot over the years, and it's one that would benefit Entourage users across the board. There are companies working with the Entourage database, like Mark/Space. But it's not like you just grab the info from MSDN and go. Even with the upcoming Sync Services and Spotlight support, being able to work with the Entourage database in a safe, supported manner would allow for more workflow with Entourage beyond what you can get with AppleScript. If nothing else, it would make backup of Entourage data a lot nicer than the current ''all or nothing'' approach.
A database API though would only be half of the story.
The other part would be a plugin API. This is nothing new. The rest of Office has had one for years -- decades even. If done in a safe, secure manner, (since you're not trying to tap into the entire OS with this, safer gets simpler here), then Entourage could reap the benefits that everyapplication that allows plugins gets. You'd get things like Plaxo; RSS reading in Entourage; better IM integration with iChat or non-MSN Messenger systems -- all kinds of things.
Look at the size and breadth of the Outlook plugin market. Ask Adobe how many sales that plugins have helped drive. Heck, they've kept Quark alive if you really think about it. Entourage, even with Sync Services and Spotlight, still is too much of a closed system, and it's overly limited by this.
Remote Desktop Client Improvements
First of all, I love the Remote Desktop Client. I could not do my job without it... literally. It would be impossible. Email, a good web browser, and Remote Desktop are my three critical applications. But, there's some things that are needed here.
For one, I really need the ability to easily open multiple sessions to multiple machines. I sometimes have three to five Remote Desktop sessions going, and it's a pain to get this working well.
Read on to see what Welch has to say about making improvements to Messenger and NTFS support.
Look at Kerberos integration for Remote Desktop itself. Once I'm in a session, I have all the kerb tickets I need on the Windows host. But Remote Desktop Itself isn't kerberized, so that's an extra step.
Enabling Remote Desktop to play well in the OS X Single-Sign-on environment would be a real plus for sysadmins. Drag-and-drop support for file transfers. Yes, you can indeed, have your local hard drive mount within the Remote Desktop session, but drilling down to your desktop to get to a file that you're looking at is just annoying. Remote Desktop already has great shared clipboard support, but it really needs the ability to just drag files to and from the Windows host.
Finally, what about direct application launching? Instead of firing up the entire Windows desktop, then launching the application, just launch the application via double-click. (My request for kerberization of Remote Desktop comes in handy here.)
This is a feature of Citrix, and a pretty handy one at that. It makes managing Remote Desktop users easier, and also helps in cases where Virtual PC or a full Windows Remote Desktop session is overkill, such as when you only need access to a single Windows application.
Microsoft Messenger Improvements
I can't recall anyone on the Mac who uses Messenger because it's better. There's no video, no audio, no scripting, and without the Live Communications Server, you're stuck without access to pretty much every Mac user you know.
This is one of those cases where the Mac BU needs to fork a product more. To Mac users, unless you're in an environment with Live Communications Server, Microsoft Messenger is simply of no practical value beyond being able to say you have it. If it's going to do more than just take up space, it has to have quality A/V support, and be able to talk to iChat/Jabber users without needing to pay for Live Communications Server. Otherwise, it'll just sit there or get deleted.
I know the Mac Messenger team puts a lot of work into the product, but every time I think about using it, I can't come up with an real reason touse it.
A full NTFS driver implementation for Mac OS X
Yes, I do know that Mac OS X has basic NTFS support. In fact, it's let me bail a few Windows users out of trouble. Slap the drive in a Firewire or USB case, plug it in, it mounts, and voila, I can pull files off of it. (Okay, yes, I really do enjoy the look on Windows people's faces when I pull off this trick without needing a custom boot CD, or needing to do manual mounts in Terminal. Drive in case, plug case into Mac, BAM! You've got NTFS.)
But it's missing a lot. Write support is very limited, and you can't really use NTFS to its full abilities. That's a shame, as NTFS is really a great file system. Full NTFS support, even if it couldn't be a boot drive, (although that would be socool), would be of great benefit to people like me. Not just reading, but writing, compressed filesystem access, encrypted fileystem access, full ACL support -- I could make great use of all of that.
It would be very nice, if nothing else, for Virtual PC users to have the ability to have a separate drive or partition formatted as NTFS, instead of the single file we use now, which is such a pain for backups.
Mac MMC snap-ins for Active Directory tools
Managing Macs in an Active Directory environment is quite honestly, impossible without a copy of OS X server around. There's just too much that you have to do, from things like Workgroup Manager and Server Admin. If we had a set of MMC snap-ins to allow us to manage our Macs better from the Active Directory tools, well, I know I'd be happier. And I know I'm not alone.
It would allow Active Directory administrators to manage Macs in a way that they are used to, with the tools they already have. Yes, it's not like Workgroup Manager, and the other Apple tools are hard to use, but they have a heck of a price premium at the moment.
I completely agree that Applebears primary responsibility here, but I also don't care who makes the tools I need. I just want them done. If Apple won't do it, then Microsoft is a great choice too. I know I've been asking Apple about this for a while, and the response is obvious, since I'm asking Microsoft to do this.
That's the list. It's not too long. I wanted to be realistic in my requests, but still cover the ground that I see needing covering. I don't expect the Mac BU to do everything on this list by themselves either. Partnering and working with other divisions in Microsoft, or third-party ISVs will work, as well. I also don't think anything on here is all that unrealistic, or lacking a business case.
If any of you sees something that you like on this list, or you think of something that shouldbe on the list, contact whomever you work with at Microsoft and ask them about it. The more direct requests that Microsoft gets for things, the better a business case they can make for getting it done. No, that's not a guarantee that it will happen. Some things just would take longer than they're worth, like Access.
But if you never ask, you never have a chance of getting anything.