Risks and Rewards

A little over two years ago, I wrote a long post about bugs. In that post, I briefly discussed a number of reasons why not every known bug gets fixed in any particular dot-release of a product. I’m going to go into a bit more detail about one of those reasons today, so allow me to quote myself from that post:

Some bugs are easier to hit, but fixing them may have a high risk of regression and may cause another bug that is even worse. One example might be a performance bug in Excel’s recalc engine. We could fix it and make things faster, but currently the code calculates correctly (albeit slowly) and any fix might totally break all function dependency analysis. It is sad but safer to leave things alone.

Let’s look at performance as an example. Over the ten or so months that Office 2008 has been available, we’ve received a lot of feedback about the suite. One of the most common areas mentioned is performance, such as the amount of time it takes Office apps to boot, the amount of time it takes a chart to draw, or the amount of time it takes Excel to recalculate a worksheet in particular. Each of these three areas are places where we’ve actually put in some significant research and investment in improving Office 2008 performance. Each of the Office 2008 updates (12.0.1, 12.1, 12.1.1, 12.1.2, and 12.1.3) have contained a number of performance improvements, among many other fixes. That said, we’re continuing to make additional improvements. Some of the code changes needed are invasive and we’ve had to evaluate the risk-vs.-reward tradeoffs and make decisions to delay these changes until a more appropriate time.

Let’s look at one of these scenarios. Pretend you are working in Excel and want to create a simple line chart with a large data set that contains as many as 30,000 data points. I’ll presume that you have a pretty good monitor, perhaps running at a resolution of 1600×1200 pixels. Now, your chart probably doesn’t actually fill the entire screen from left-to-right — after all, you need space to show the columns of data that you are working with, right? So let’s further assume that your chart is roughly 1000 pixels wide. That means you are displaying 30,000 data points in 1000 pixels, or about 30 data points per pixel. Even if not all of those data points fall directly on top of each other in the y-axis, the only possible line to draw to connect all 30 of those points in one vertical pixel slice is a single line up and down and up and down again, on top of itself many times. Your chart looks kind of smushed together. Or, let’s pretend for the sake of simplicity that all those 30 data points are approximately the same on the y-axis, and you just get one single pixel, drawn over and over and over again. And, as you may have noticed, the current charting engine that we share with Windows Office is rather sluggish as it faithfully draws that line or pixel over and over and over again.

Now, the fact that 30 data points end up in one pixel slice on the x- axis isn’t the charting engine’s fault, as it didn’t choose the data set or the size of the chart — you did, or you at least accepted the charting defaults. Now, to improve things, you could stretch the chart out to be a full 1600 pixels wide, right? But that doesn’t help much; you’re still at almost 19 data points per pixel. Or, if you had $17,207+tax on hand, you could set up a Mac Pro with four ATI Radeon HD 2600 XT video cards and eight 30″ Apple Cinema Displays (2560 pixels of horizontal space per monitor) for a total horizontal space of 20,480 pixels, which is still not enough space to achieve one data point per pixel! Ok, so perhaps it’s not reasonable to ever expect that such a data set would ever have more than one pixel available for each data point. What would you do? How might you redesign the charting engine to handle this?

One option might be to only plot at most one data point per pixel. But, how do you decide which of the 30 data points is the best one to plot? The first? The middle one? The average value? Do you add math to best-fit the overall line, which adds processing time, which is what you are trying to cut down on? I’ve only mentioned one single possible change, and there are many. The point here isn’t to actually craft a redesign in this blog post (or in the comments either…), but to demonstrate that a redesign can be a complex thing — I’ve posed some design questions and probable decision points already, and I haven’t even considered how the current code is actually designed. (Neither have you, since you don’t have access to it!)

This example is just a very long way of saying that whatever redesign is planned, it has to fit into the current architecture of the code or be willing to accept the risk of changing that architecture and possibly breaking something else. That breakage may in fact be worse than the current bug. If we make a major change to the code, we run the risk of introducing a variety of different possible bugs — incorrect visual representation of the data, or a crash, etc. Testing architecture changes is particularly challenging because it’s impossible to craft a series of tests that exercises every possible type of data that could be charted, and if we miss one edge case we could let a critical bug slip through that is worse than the current problem. We’d rather make the change when we have sufficient testing resources lined up for a longer period of time than we usually have for a dot-release. That way we have all the test coverage needed to validate the change, and is why a bug fix in a feature as important as charting may be delayed.

Bear with me while I shift gears now, and talk about another issue that the MacBU has heard a lot about: Office 2008 and the OS X feature called Spaces. If you read through the links in that previous sentence, a couple of themes pop up:

  1. Mac Office 2008 doesn’t work properly with Spaces
  2. It happens most often in Word or when the Formatting Palette is open
  3. People rarely see the bug in non-Microsoft applications
  4. People assume the Mac Office 2008 code base is the cause of the problem

Let me give you some of the background of the Formatting Palette, to help explain why the problem shows up so much more readily in Office 2008 than in Office 2004 or in other applications.

When people talk about the “Formatting Palette” in Office 2008, they usually mean the Toolbox window. The Toolbox is actually two separate windows, bound together by Carbon Window Groups. The first window has the title bar and the row of buttons across the top (the buttons that toggle between the Formatting Palette, the Scrapbook, the Reference Tools, the Object Palette, and whatever else is there that I can’t remember off the top of my head.) That first window is a true floating window created by OS APIs. The second window is everything below that row of buttons, and is the instantiation of one of those toolbox items. These windows are slightly customized, in that we tell the OS to create them with no border or shadow, again through OS APIs. When the Formatting Palette is showing, you’ve actually got the root toolbox window showing first and then the FP window bound tightly to it, on top in the z-order. If you click on the Scrapbook button, the FP window is destroyed and a new window is created to hold the scrapbook, and that new window is bound against the root window. I think that Spaces and Exposé don’t take the window bindings into account (my understanding is that they manipulate windows at the Core Graphics level, which is a lower-level private system interface upon which both Cocoa and Carbon windows sit), and that is why Spaces and Exposé seem to get confused by the root floating window and the upper child window.

The reason MacBU uses this window separation is that most of these child windows are hosted in different modules of code, most of which have their origins in different architectures. The Carbon Window Group APIs allow for very rich and precise control over how windows are presented to the user, and gave us the ability to combine UI from a variety of sources in our codebase with minimal rearchitecting of each of the individual components. The Scrapbook window, for example, is a PowerPlant window because it actually lives deep in the Entourage code (due to the fact that Entourage is currently PowerPlant-based, and that was the easiest way to get access to the Entourage database). PowerPlant is very picky about owning its entire window, which is why we use a separate window here — it misbehaves rather badly if you try to put PowerPlant objects in a sub-frame of a window that is not fully under PowerPlant’s own control. The Formatting Palette is actually a special instantiation of the toolbar code, which has its own assumptions about the sort of window it lives in, and the Compatibilty Report is actually an instantiation of what was originally a modeless dialog.

We have long-term plans to overhaul the entire architecture of the Toolbox and all its clients to use Cocoa, but that didn’t happen in 2008. The Cocoa AppKit window APIs do not yet contain functionality that supports the full richness of window management features that the Carbon APIs do. The Toolbox and its use of Carbon Window Groups were introduced in Office 2004 and predate both Spaces and Exposé. The Office 2004 Toolbox has the same issues with Spaces and Exposé, but you only notice it if you show the Toolbox. In Office 2004, the Formatting Palette was separate from the Toolbox, so the Toolbox was not shown by default. In order to reduce the amount of screen space the Toolbox and Formatting Palette obscured at the same time, we merged the two together early in the 2008 cycle, long before Leopard and Spaces were demoed or available for us to test with in beta.

After we received a beta of Leopard with Spaces, we tested our apps and identified a number of issues that our apps have with the feature. We had an engineer spend several days digging into these issues. He did some serious spelunking into our windowing code and determined that we were not moving the windows incorrectly in our code so we reported them to Apple to investigate. Apple has fixed a number of problems with Spaces in OS X 10.5.3, but some still remain.

So, let’s circle this discussion back to the point I opened with, and the real point of this post: some changes are just too risky for dot-releases, and every company that writes software has to deal with that. Microsoft does and certainly Apple does too. I don’t know the Spaces code — as I don’t work for Apple, I’ve never seen it. Microsoft and Apple work together to troubleshoot customer issues as situations warrant, and as part of that joint effort I’ve spent some time talking to some of the Apple Carbon and Spaces developers over the last few weeks about Spaces. We wanted to see if there’s any sort of change we could make in our code to avoid the issues. If there was anything we could reasonably change in our code at this time I would love to do so. However, changing our windowing system to not use Carbon Window Groups entails a complete rewrite, and is not something we can feasibly do in a bug-fix release. Given the direction Apple is taking with OS X, any significant rewrite of our windowing system should be done in Cocoa, and that is a tremendous task to do in a dot-release. It would almost certainly cause other serious bugs as I alluded to in the charting example above. The Apple developers I’ve spoken with have been unable to come up with any simple code changes to that we could make to work around the issues, and have indicated that our code is generally acting correctly.

For now, you’ll have to wait for Apple to release an update to or new version of OS X where Spaces works with apps that use Carbon Window Groups. Our User Experience team has put up a brief help topic about the issue. We’re keenly aware of our customers’ frustration with Office 2008 and Spaces, and we will continue to work with Apple to help find a solution or workaround. Please continue to share your product experiences with us on Mactopia, or privately with me if you wish. As long-time software developers, it’s frustrating to me and to my peers when we’re unable to fix every problem instantly. Improving your experience with Mac Office on a continuous basis is part of our job. Sometimes we can do it with a quick fix, sometimes not. Your input helps us get it done.

(Edited to clean up the extraneous formatting tags in the last paragraph. Also fixed spelling of Mactopia.)

42 thoughts on “Risks and Rewards”

  1. Honestly, long before 10.5.3 I got so frustrated with Spaces that I turned it off for good. I’ll probably try it in 10.6… hopefully, by then Apple will have fixed this problem, too.

  2. Interesting read, and it’ll make me less annoyed about the Spaces issue next time I use Office :)

    Unlike Steven above, turning off Spaces isn’t really an option for me. It would be like bashing my thumb with a hammer on purpose, as I use a configuration of 9 spaces/desktops, and I’ve generally got things running on at least 5 or 6 of them. (Yes, I know I’ve got N.A.D.D., http://www.randsinrepose.com/archives/2003/07/10/nadd.html …lol)

    Cause of this, I did suffer through the annoyances, random desktop switching with apps spread across more than one desktop and so on, which wasn’t fixed till 10.5.4.

    But anyway, I hope Apple are able to bring a fix to the table for Carbon Window Groups with 10.5.6 :)

  3. “And, as you may have noticed, the current charting engine that we share with Windows Office is rather sluggish as it faithfully draws that line or pixel over and over and over again.”

    and

    “When people talk about the “Formatting Palette” in Office 2008, they usually mean the Toolbox window. The Toolbox is actually two separate windows, bound together by Carbon Window Groups. ”

    Are just two examples of:

    1) I don’t care. This is what we pay you to solve.

    2) Why cobbling together code from windows for a Mac app is never a good idea.

    3) the weakness of the MacBU to truly and effectively separate themselves from ‘the motherhsip’ and therefore are forever trapped inside the mothership’s business strategies, which are not in line with us the user’s needs.

  4. 1) The harder the problem, the more effort it takes to fix it. MacBU is a small group relative to Win Office. They have to think about allocating their resources. Oh- but I guess you don’t have that issue since you’re such a genius. Apparently you have the cure for cancer but you’re still waiting for someone to throw a dollar your way.

    I mean seriously, go visit notalwaysright.com or something. “I don’t care”… give me a break.

    2) It is a good idea and if you had taken 10 more seconds to think instead of flame you might have realized it. The big key about Mac Office is compatibility. I’ll let you fill in the rest of that one.

    3) Business strategies = user’s needs. That’s why this blog post even exists. It’s written by a person for people who care.

    Anyway, I guess my comment can still be counted as criticism – there are still things on Office 2008 that feel a little 98-ish, as in they seem to have the same quirkiness from Office 98. Maybe that’s because of the different architecture of everything, but each time it’s felt like the prevailing feeling is “we have all these things to fix, but we can’t get it all done, so we’re going to fix this subset so it looks better, but we’ll leave the heavy lifting for later.” Obviously porting over the graph system was a big challenge, but is there going to be a time where everyone in teh MacBU sits down and rewrites the entire set of apps? Maybe once you guys get more people? =D

  5. “The harder the problem, the more effort it takes to fix it. MacBU is a small group relative to Win Office”

    That’s my point.

    “Oh- but I guess you don’t have that issue since you’re such a genius.”

    Genius? Hardly. That’s why I part with hard earned dollars to folks smarter than me to use tools that are focused on the user’s needs, and not the tool makers.

    As far as the other topics thrown this way (towards a user)~tough love is tough. Get over it.

  6. My belief is that old apps should look and feel like old apps. They should never get modern and should never undergo a face-lifting with the sole goal to hide old scratches. For a small utility a major overhaul might be a proper thing to do. For such a complex piece of engineering such as Office, the most of development work should be to keep it running and keep it being as useful as it was 10 years ago. From that standpoint Office 2008 is good enough. All the rest is a marketing fluff that has nothing to do with user needs. Go ask Photoshop people if they want the thing to be all Cocoa. Their answer will be: “keep my hotkeys, keep the behavior, make it faster with ever growing image sizes, make it use larger memory, add more intelligence behind the scene and I’ll be happy”. Why we, veteran users of MS Office, are constantly asking for some major change? What for?

    Yes, Entourage obviously needs some improvement to better service current needs of people. We can’t afford its terrible handling of HTML, its inability to lookup Exchange contacts without involving LDAP, incompatibility with Time Machine, etc. All these things are well known. But for the rest of it: is there anything in Entourage that really needs to be fully redone?

    All in all I believe MS Office for Mac is an excellent piece of software, very well crafted, obviously worth the money. I tried other options several times (such as OpenOffice). Always switched back to MS Office at the end.

  7. I think you’re underestimating the impact of the Spaces bug, as if it were some cosmetic fix that would impact other important functionality. From my perspective, the bug makes Office 2008 (especially Word and Excel) almost unusable.

    I know a bug of this type is an interaction between the operating system and the application, but it sounds really, really lame to say “It’s Apple’s fault” when a) almost no other applications have this behavior, and b) you’ve had a year to fix it.

    At any rate, thanks for explaining the issues, and for your comment on my blog.

    1. “From my perspective, the bug makes Office 2008 (especially Word and Excel) almost unusable.”

      AMEN – and here in March of 2009, it still is almost unusable. How this continues, just blows my mind.

  8. Yes, Entourage obviously needs some improvement to better service current needs of people. We can’t afford its terrible handling of HTML, its inability to lookup Exchange contacts without involving LDAP, incompatibility with Time Machine, etc. All these things are well known. But for the rest of it: is there anything in Entourage that really needs to be fully redone?

    I’d rather have E’rage’s handling of directory lookups via a single, consistent, standard mechanism than Outlook’s completely split personality handling of Exchange and LDAP. LDAP use in Outlook blows chunks, and there’s a lot of LDAP out there, *especially* in the Mac userbase, something E’rage does have to deal with.

    LDAP is an approved, supported way to interact with Exchange’s GAL, so the fact that E’rage uses it is not bad by any definition. The *implementation* could use some fixing, but LDAP is not “bad”.

  9. You got me wrong. I am not against LDAP at all. I am talking about the support for GAL lookups without LDAP, the functionality that is available even on iPhone (as well as Windows Mobile). Companies normally provide LDAP support inside (due to AD being actually an extension to LDAP). But they are normally reluctant to have the same LDAP server published to the Internet, even with all the security attached. That’s why many of us suffer from not being able to access GAL working from outside. Yes, there is VPN, but that is too much trouble for such a basic thing as mail communication.

  10. Funny you’re comment about using OpenOffice. I was so used to Office 2003 on windows, I found that OpenOffice.org 3 actually was more like 2003 than 2008. Therefore, I used what I was familiar with.

  11. It’s not much of a secret that most business user of MacOS would be using Windows if it wasn’t for Office for Mac. So for that I’m grateful that MS supports OS/X with these products. In fact, I wish they would do the same for Visio if there’s any business case for it. So while there are cracks in the some of aspects of the UI, overall Office 2008 is the rosetta stone we need if we want something other than Windows machines.

  12. Thanks for reaching out to me via twitter to explain my Spaces/Toolbar issues. It’s great to understand where the problem is coming from. Just something I’ll have to deal with for now.

  13. I think you could at least make this problem manageable by fixing the Toolbox. If you assign Word to say Space 1 then you will not experience any problems with main Word window and switching spaces, but you will still experience issue with the bottom part of the tool box. The fact that you are using a windows group for the formatting palette is just sloppy coding in my opinion (You clearly reused the toolbox code from 2004 in 2008). However i think you could make a very simple fix to the problem: when a user switches spaces you should kill the the toolbar window and when a user a user switches back to the space and brings word into focus you should reinitiate the toolbar.

  14. Like J, I also think you can make the Spaces issue manageable by fixing the Toolbox. Unlike the Mac BU team though, my solution would be to kill the Toolbox completely. Really. It’s a mess. You have 95% of the program commands crammed into a single panel in a tiny, floating window that “helpfully” auto-collapses when it loses focus. What if I might want to go right back to that set of buttons again? You’re needlessly increasing the number of mouse-clicks needed to do anything important. It frustrates the hell out of me, and that isn’t even taking into account the fact that the Toolbox floats above the other Word windows, often covering up parts of the document I am working on or at a minimum blocking access to the scrollbar handle. Add in that most of the panels in the Toolbox are darn near useless – honestly, aside from the Formatting palette I have never used any of the other options – can you begin to see why this Toolbox is a useless mess?

    Every time I go home and work on my Windows machine, running Office 07, it just drives home exactly how awful the Office 08 interface really is. The Ribbon and pop-up context menu are ridiculously simple yet manage to give me quick, ready access to 90% of the commands I need, often without moving my mouse more than an inch. The Ribbon interface feels more Mac-like to me than anything I’ve seen in Mac Office, ever, and I started using Mac Word in 1992.

    Also, while you’re at it, can you make Excel stop changing the size of open windows every time I switch between them? It drives me batty. Respect the window size I choose, don’t change it. Ever.

    PowerPoint, I give you props there. It honestly is the only Office 08 program that seems to work as expected, with essentially no issues. Great job. Now can you make the rest work as well? We’re waiting, and we’re losing patience.

  15. Please make this more transparant.

    I’m a big apple fan, but I’m more than aware that their coding is far from perfect!

    They’re also very secretive about what they’re working on, which perhaps works for iPods, but really frustrates the end user when all we want to know is that our frustration is being channelled into something productive when we give feedback.

    Please do all that you can to make this more visible. Knowing that there is some intelligable reason as to why these two interfaces are not working really helps a frustrated user.

    I had to look right down to the third page of comments on something from the second page of google to hear that there was something not quite right with the implementation of spaces. Spread the word and reduce stress levels; Spaces is not perfect yet and the amount of time required to fix the problem is not financially viable right now. *sigh of relief*

  16. I was glad to see Office 2008 come to life, myself. I do have to wonder, however, *why* any of the Office 2008 applications are glacially slow to load. I know that one of the reasons the Windows version, 2007 (and even 2003), is able to load so quickly is that, by default, Office is partially loaded at boot. 2008 should at least *offer* this functionality. The 2008 applications take SO long to boot (on an otherwise incredibly speedy new MacBook Pro with 4 gigs of RAM) that I have had to resort to iWork to do anything that I need to do *now* rather than later.

    Another thing I fail to understand is why Entourage is SUCH a far-cry from Outlook and why the data files are not inter-compatible. Thus far, no one from the MacBU seems to have addressed this.

    Outside of just basic performance-enhancement, are ACTUAL speed increases something Microsoft is going to be able to do with 2008?

    1. Marvin:
      “Another thing I fail to understand is why Entourage is SUCH a far-cry from Outlook and why the data files are not inter-compatible. Thus far, no one from the MacBU seems to have addressed this”

      The why is easily answered – it’s because Entourage was designed from the ground up as a completely different application. It has added Exchange functionality that has improved with each release, but it is NOT outlook! See this page for details:

  17. I appreciate the explanation, but is there really no workaround? E.g., stick the toolbox contents permanently in the main document window? (I wish there was an option for this anyway to avoid multiple floating windows.)

    Or, I wish Word could automatically minimize the toolbox before Spaces switches, that would also reduce the problem I suspect.

    We are paying customers after all, and the bug has been around at least a year (more)? Right? This must be your biggest single bug. You should at least try to reduce the impact.

    Thanks.

    P.S. BTW my own workaround is to set up Command+T to toggle the toolbox open and closed. If you keep it closed all the time, it seems like the problem happens much less often. (I have not empirically measured but seems like it.) Go to Tools->Customize Keyboard. In the View category there is the command ToggleOfficeToolbox, which you can tie to whatever keyboard shortcut you like.

  18. For the most part, I like the toolbox.

    But I’m willing to keep it closed if it will stop Spaces from spazzing out.

    The problem is, it doesn’t.

    Here’s an example of what happened to me before. I was working on a Word Doc in Space 2. Then I switched to Space 1 to refer to the Word doc there. I began reading it. About five full seconds later, I magically get switched back to Space 2. I wasn’t even touching the keyboard or the mouse. I don’t understand how the hell it happened.

    But it happens to me a lot with Word.

    And my toolbox is closed the entire time :(

  19. Alright, I’m back with some insight.

    If you want an example of a “toolbox”-like window that behaves well, check out the “Table…” item in the Text Edit menus. It opens up a little window that’s used for formating tables, and you can have tables open in multiple text edit docs at the same time, SWITCHING BETWEEN SPACES, and doing whatever you want… and it’s fine with it.

    It might not look as flashy as the MS Office toolbox, but damn, it works.

  20. Alright, I understand everything involved in plotting lots of points repeatedly, even if they fall on the same pixel. Sure, you could devise a fancy, novel way of reducing the number of points to trace. But before we talk about dramatic innovation to fix the problem, why don’t we first take a look to the past, when functionality already existed? How does the Windows ’07 version of Excel do this differently that my same chart traces/retraces up to 100′s of times faster? How did 2004 for Mac do it, where again, it still traces in a dramatically shorter period of time? This is an issue that arose in 2008. Is there a reason why the fix isn’t as simple as removing whatever steps took the overall process from functional to dysfunctional?

  21. Sorry to sound like just another flamer. But I count my upgrade from 2004 to 2008 as a waste of money.
    Besides the still unresolved issues with spaces, slow startup etc., there is the annoying tendency of Entourage 2008 to rebuild its database on reboot, preventing you to access your Emails for the first 10 minutes after booting your Mac. Then the removal of 2004′s “Empty cache command”, which was a lifesaver, if you were unable to open an IMAP folder in Entourage 2004. The still existing “Repair Message List” command is not a full substitute.

    As a consequence, I’ve reverted to 2004 (except Powerpoint, where the new features slightly outweigh the introduced bugs). 2008 is still installed on my Mac and I give it a try with each dot-release (like today), but so far none of my big issues with 2008 have been solved.

    Frankly I don’t believe any more we will see these things get fixed in Office 2008. More likely there will be a complete rewrite (Cocoa ?) as Office 2010, 2012, …

    Sad for those, who spent their money already on 2008!

  22. Adobe and Microsoft should jointly run a technical blog called: “Don’t blame us, Apple did it.” Granted, Adobe and Microsoft hate each other. But they share quite a bit of camaraderie, having both stuck with the Mac platform through thick-and-thin, ever since the Classic 68k days. Never mind Mac Office and Spaces — you should read some of the flames that Adobe got for 64-bit Photoshop.

    Mac Office is falling farther and farther behind Win Office. Frankly, the one-year offset doesn’t seem to be enough to keep up. Wasn’t so bad back in the days of Mac Office 98. But ever since the x86 transition, Mac BU seems to be putting out fires and punting ever more features to the next version. Meanwhile, Win Office is not standing still. And considering that Adobe took a one-version development hit for Cocoa …

  23. Thanks for the explanation on the bug. I understand that this is a problem at the root of how windows are displayed in Mac OS X, and its a difficult one to solve.

    The problem is that I don’t care, and neither do any of the other users of Office 2008. The fact that you have difficult software engineering problems is nothing new; all software companies have difficult software engineering problems, that’s the nature of programming. Even more so, this isn’t something you should be even discussing on a public blog. It sounds to me like you’re saying, “this is difficult, so we aren’t doing it.” Apple introduced Cocoa and Carbon almost a decade ago at this point, and even back then they had a roadmap which ended with a completely cocoa-based interface.

    Microsoft has had plenty of time to work on a complete rewrite, as Adobe did a few years back. It seems that they chose not to go this route, and now they’re stuck with the bad choice of either continuing with sluggish and buggy software or committing to a multi-year rewrite process after everyone else has already adapted to the new software design. Either way, customers are unhappy and Microsoft loses out as people switch away from their software.

  24. Hi, and thanks for this very eye opening post. Thank you also for this detailed explanations about the Spaces bug. The point is, it is not the costumers task to forgive the big Microsoft Company any incompetence! We pay Microsoft a LOT of money and we expect performance!

    I must totaly agree with Eliezer and nearly all the other posts here.

    1. The Spaces bug makes Office 2008 unusable.

    2. Noone cares who’s fault this bug is, MS Apple or whoever.

    3. Spaces is perhaps the most important new feature in Leopard. So there is no question that Office 2008 must work with it perfectly.

    4. If rewriting the whole Toolbox code in Cocoa is the only way to fix it,- then damn!!! just do it! You should have started to write everything in Cocoa 6 years ago. We pay a lot of money for this office suit so use it to fix this bug! We don’t care if you have not enough software engineers. Just hire more. You are the big Microsoft. So why should the Windows Office crew be much bigger then the apple crew? The point is no one cares how big the effort is to fix this bug. Just fix it and do it fast. Even freeware like Neooffice can handle spaces… It’s a shame for MS.

    Sorry for being so rude. But attitude of Microsoft is just embarrassing.

  25. Schwieb, your post is all well and good. But why not just tell the blunt truth to everyone; 1) PowerPlant is in use all over Office, and 2) such code was NEVER supposed to make it to Intel.

    Your team had plenty of time to re-implement plenty of Office over to Cocoa, and at least pure Carbon. I can’t even begin to imagine what kind of job it was to wrap PowerPlant inside Carbon so it would compile on Intel. Sadly, such a feat is extremely impressive (and extremely time-wasting). Software Engineering 101 tells us that if we need to spend 8 months porting someone else’s (Metrowerks) product so we don’t have to rewrite ours, YOU’RE DOING IT WRONG!

    So instead of doing the responsible thing and creating a decent product, Office sucks, and people are finally starting to give it up in favor of OpenOffice and iWork.

    Way to go MS!

  26. The spaces/toolbar problem could be solved so easily. I guess there is some kind of event that is raised before/when the space changes. Just hde the toolbar or make word inactive (eg. focus finder) and it won’t get moved to the next space. If you use cmd-tab to jump to another application on a different space, the toolbar doesn’t get moved because the app is activated, word is deactivated and the toolbar is hidden …

    What was said about performance has nothing to do with 30000 pixels or what so ever. Sometimes I feel like being near a singularity because word is so slow. Add a picture and then wait a few seconds before it is drawn. There a plenty of other situation, where the speed just sucks. And my documents are not even big. Just admit it, the codebase is a mess. The implementation is just bad! Making such an ugly hacked toolbar … Why not using a plane dumb window?

    Bad rendering – texts are jumping back from the next side just to be not really there, where one can see them. You have to scroll up and down to make word redraw the entire area correctly. Clicking on the scrollbar doesn’t bring you to the corresponding area in the document, though the scrollbar grabber(how is this thing called?) gets moved to that place. For you microsoft people who don’t know that: there are two options in the system preferences! Clicking to the scrollbar can really mean to scroll to that place (like on windows) or really jumpt there!

    And why the hell is there no VBA? Is it that hard? This is one of THE BIG REASONS to use MS office.

    As I first used the I was totally shocked. How can such a big and powerful company like MS bring such crap to the market? Did anybody test this? Then the first updates came out (promising perfomance improvements, etc …) and I couldn’t install them, because the installer didn’t find my MS installation … Such things MUST NOT HAPPEN! Shame on you, really!

    If openoffice wouldn’t bad so bad I’d use it. But unfortunately it’s slow, has bad rendering, bad usability. So why do I still use office 2008? Because I need to have compatibility to windows office 2003/2007. That’s the only reason …

  27. Ok, fault-finding aside, can we expect this to be fixed (or quickly fixable) in Snow Leopard? Sorry if this is an ignorant question, but this is the first good detailed discussion of this I’ve seen– it’s just a little outside of my non-engineer competence.

  28. You want a simple fix …. just don’t combine every single palette into one global all knowing toolbox. The formatting palette should be its own palette. Everything else can be thrown into a second pallete (that no one will ever use). That way you don’t have to use multiple windows on a single toolbox.

    The simplest solution is usually the best solution. If Spaces doesn’t support multiple grouped windows, don’t use multiple grouped windows!

  29. Thanks for reaching out to me via twitter to explain my Spaces/Toolbar issues. It’s great to understand where the problem is coming from. Just something I’ll have to deal with for now.

  30. Thanks for the explanation on the bug. I understand that this is a problem at the root of how windows are displayed in Mac OS X, and its a difficult one to solve.

    The problem is that I don’t care, and neither do any of the other users of Office 2008. The fact that you have difficult software engineering problems is nothing new; all software companies have difficult software engineering problems, that’s the nature of programming. Even more so, this isn’t something you should be even discussing on a public blog. It sounds to me like you’re saying, “this is difficult, so we aren’t doing it.” Apple introduced Cocoa and Carbon almost a decade ago at this point, and even back then they had a roadmap which ended with a completely cocoa-based interface.

    Microsoft has had plenty of time to work on a complete rewrite, as Adobe did a few years back. It seems that they chose not to go this route, and now they’re stuck with the bad choice of either continuing with sluggish and buggy software or committing to a multi-year rewrite process after everyone else has already adapted to the new software design. Either way, customers are unhappy and Microsoft loses out as people switch away from their software.

  31. Ok, fault-finding aside, can we expect this to be fixed (or quickly fixable) in Snow Leopard? Sorry if this is an ignorant question, but this is the first good detailed discussion of this I’ve seen– it’s just a little outside of my non-engineer competence.

  32. You want a simple fix …. just don’t combine every single palette into one global all knowing toolbox. The formatting palette should be its own palette. Everything else can be thrown into a second pallete (that no one will ever use). That way you don’t have to use multiple windows on a single toolbox.

Comments are closed.