"...something like 90% of them were features already in the product." I encountered this myself just this week.
Someone sent me a Word document they had made changes to. They did not use Track Changes/Insert Comment, nor did they use the age old method of using a different font color for changes and making comments by adding text in brackets or italics, prepended with their initials like Outlook does.
I wasn't looking forward to manually comparing the two documents. I was sure there would be a 3rd party add-in somewhere that could do this for me, but I really didn't want to go down that rabbit hole. I discussed it with a colleague who said, "I don't think Word has that function built-in." Neither did I, but I decided to search online anyway just to see and...it does! Adding insult to injury, it's only a few icons to the right of Track Changes. Despite having used Word since Word 95 and using WordPerfect for DOS prior, I had never noticed it because I never needed it, and never went looking for it. Previously when sharing documents, people had used Track Changes or some type of homegrown method like I mentioned earlier.
I have no idea how long that function has been in Word, but it's there and worked perfectly.
This is an amazing account and I look forward to the successive discussion. Meanwhile, highlights for me.
“A bug is any time the software does not do what a customer expects”. Amen. A thousand times Amen. And getting an incident report is valuable information, not something to be deflected to a Forum, Discord, or elsewhere.
(Aside: I was and remain a big fan of CUA. That's how retro I am.)
"Our user interface mapped directly to the implementation of the product—literally the data structures and structure of the code—and not to the results that a person was aiming to achieve. This was incredibly important for us to internalize." Yes, my mantra in walk-throughs and other situation is always, don't tell me the code, first tell me what it is for, and then tell me how the code accomplishes that. (Substitute whatever for "code.") At the UI/UX level, there's more abstraction than that of course. But always, what is it for? I find that Design Patterns can help but not the way they came into object-oriented software.
"It wasn’t perfect, but it was our menu structure and our customers liked it. So much so, it was widely emulated across the industry. That made it carved in stone." Ahah! The coin drops about supposed competitors for Office.
I just installed the latest release, Apache OpenOffice 4.1.11 (x86 only, clumsy installer). There it is, &File, &Edit, &View, &Insert, F&ormat, T&able, &Tools, &Window and &Help. Grabbing the latest LibreOffice, 7.3.2.2 (x64 MSI installer), the Menu bar adds St&yles and Fo&rm. But it is hidden by default and a Tabbed view is there with the a clickable button to toggle appearance of the menu strip. The tabbed view is Ribbon-appearing (and described as such) but definitely not a ribbon, and not easy to collapse.
Now I understand the appeal of "competing" with Office 2000/2003. (There are still people who build Apache OpenOffice for OS/2 and those like me who owns a car until his feet go through the floorboards.) So it is free, it runs on Linux desktops (and is in distros), and it offers some sort of interoperability with simple-enough Microsoft Office documents. The 80-20 rule says forget-about-it and that has held up. Amazing. As much as Sun/Oracle/IBM wanted a different outcome (or at least a distraction for Microsoft), here it is.
Thanks for the callout, Steven...including the work of Leah and Tim. Much appreciated. 🙏🏼
For me, assessing and defining 'bloat' forced the first real reckoning of 'quant' (SQM) and 'qual' (observational) data in user research. Analysis like Cameron's helped identify 'what' and 'where' acute symptoms were occurring in aggregated usage data. It allowed us to better identify, focus, and observe 'how' and 'why' this was occurring in select tasks and activities...including the eye tracking studies you mention.
I do wonder if bloat is a natural bi-product of the scaling up of human organizations that reward endless growth. It seems as Microsoft became more hierarchical, divisions of labor solidified. Routine execution of increasingly specialized roles and tasks advanced careers in the spirit of growth. As a result, the company (especially Office) became wildly efficient and successful but also increasingly as 'bloated' as the software we were making! Perhaps this is coming in your question of 'why?' 😏
"...something like 90% of them were features already in the product." I encountered this myself just this week.
Someone sent me a Word document they had made changes to. They did not use Track Changes/Insert Comment, nor did they use the age old method of using a different font color for changes and making comments by adding text in brackets or italics, prepended with their initials like Outlook does.
I wasn't looking forward to manually comparing the two documents. I was sure there would be a 3rd party add-in somewhere that could do this for me, but I really didn't want to go down that rabbit hole. I discussed it with a colleague who said, "I don't think Word has that function built-in." Neither did I, but I decided to search online anyway just to see and...it does! Adding insult to injury, it's only a few icons to the right of Track Changes. Despite having used Word since Word 95 and using WordPerfect for DOS prior, I had never noticed it because I never needed it, and never went looking for it. Previously when sharing documents, people had used Track Changes or some type of homegrown method like I mentioned earlier.
I have no idea how long that function has been in Word, but it's there and worked perfectly.
This is an amazing account and I look forward to the successive discussion. Meanwhile, highlights for me.
“A bug is any time the software does not do what a customer expects”. Amen. A thousand times Amen. And getting an incident report is valuable information, not something to be deflected to a Forum, Discord, or elsewhere.
(Aside: I was and remain a big fan of CUA. That's how retro I am.)
"Our user interface mapped directly to the implementation of the product—literally the data structures and structure of the code—and not to the results that a person was aiming to achieve. This was incredibly important for us to internalize." Yes, my mantra in walk-throughs and other situation is always, don't tell me the code, first tell me what it is for, and then tell me how the code accomplishes that. (Substitute whatever for "code.") At the UI/UX level, there's more abstraction than that of course. But always, what is it for? I find that Design Patterns can help but not the way they came into object-oriented software.
"It wasn’t perfect, but it was our menu structure and our customers liked it. So much so, it was widely emulated across the industry. That made it carved in stone." Ahah! The coin drops about supposed competitors for Office.
I just installed the latest release, Apache OpenOffice 4.1.11 (x86 only, clumsy installer). There it is, &File, &Edit, &View, &Insert, F&ormat, T&able, &Tools, &Window and &Help. Grabbing the latest LibreOffice, 7.3.2.2 (x64 MSI installer), the Menu bar adds St&yles and Fo&rm. But it is hidden by default and a Tabbed view is there with the a clickable button to toggle appearance of the menu strip. The tabbed view is Ribbon-appearing (and described as such) but definitely not a ribbon, and not easy to collapse.
Now I understand the appeal of "competing" with Office 2000/2003. (There are still people who build Apache OpenOffice for OS/2 and those like me who owns a car until his feet go through the floorboards.) So it is free, it runs on Linux desktops (and is in distros), and it offers some sort of interoperability with simple-enough Microsoft Office documents. The 80-20 rule says forget-about-it and that has held up. Amazing. As much as Sun/Oracle/IBM wanted a different outcome (or at least a distraction for Microsoft), here it is.
Thanks for the callout, Steven...including the work of Leah and Tim. Much appreciated. 🙏🏼
For me, assessing and defining 'bloat' forced the first real reckoning of 'quant' (SQM) and 'qual' (observational) data in user research. Analysis like Cameron's helped identify 'what' and 'where' acute symptoms were occurring in aggregated usage data. It allowed us to better identify, focus, and observe 'how' and 'why' this was occurring in select tasks and activities...including the eye tracking studies you mention.
I do wonder if bloat is a natural bi-product of the scaling up of human organizations that reward endless growth. It seems as Microsoft became more hierarchical, divisions of labor solidified. Routine execution of increasingly specialized roles and tasks advanced careers in the spirit of growth. As a result, the company (especially Office) became wildly efficient and successful but also increasingly as 'bloated' as the software we were making! Perhaps this is coming in your question of 'why?' 😏
Hi - love the audio! Will that feature be back ported to the in-market articles? :)