"...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?' 😏
The product is great but the overall organization of multiple streams is a bit weird. THere are posts then you can have section which are like other streams of posts. A podcast (or video) is like a section but specially designed for audio/video. A podcast has a unique feature which is the RSS feed for use in overcast/itunes, which I think it different than the RSS feed for normal posts/sections which also can’t have audio. Otherwise a podcast has all the text features of a post. Head spinning yet? Also I’m trying to preserve the text feed of numbered sections and that isn’t working the way I had hoped. Of course no real way to test all these before trying it out.
Yeah. So working on it.
Is it the duplicate mail messages bugging you? I would like to stop that but I’m seeing a big take up in audio and about 2/3rds are using the substack web/app to listen and so the only way they find out about a new audio drop is generally by email (unless they have notifications on). I’m working on it. I didn’t want to do two emails.
I'm loving Substack. They make it so easy to publish and distribute content.
I treat my podcast as the audio book version of what I write. I actually write knowing a decent chunk of my most devoted subscribers will be listening. (which makes this season sometimes challenging...describing maps verbally!)
But last week I was crunched for time and really wanted to just publish the text to hit my Friday deadline and then use Saturday to produce the audio version (I accidently deleted chunks of my audio editing). Readers would get it delivered on Friday, but those subscribing through their podcast service (one of my favorite features of Substack) would get it on Saturday....if Substack allowed this model. Instead I just pushed through and posted them both as one later than expected on Friday.
As a reader, I do find it cumbersome to get two emails with the same title and the same content...but I feel your pane on negotiating these two mediums.
"...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.
Great story! That one has been around a long time. This is so common to hear.
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?' 😏
Such a deep question!
Or bloated!
Hi - love the audio! Will that feature be back ported to the in-market articles? :)
Thank you! I'm super happy to see the positive response to audio. I will try to come up with a plan for the first 75 posts (yikes!)
I do wish Substack let authors send the newsletter and post but then allow the MP3 to be added at a later date to that same post.
The product is great but the overall organization of multiple streams is a bit weird. THere are posts then you can have section which are like other streams of posts. A podcast (or video) is like a section but specially designed for audio/video. A podcast has a unique feature which is the RSS feed for use in overcast/itunes, which I think it different than the RSS feed for normal posts/sections which also can’t have audio. Otherwise a podcast has all the text features of a post. Head spinning yet? Also I’m trying to preserve the text feed of numbered sections and that isn’t working the way I had hoped. Of course no real way to test all these before trying it out.
Yeah. So working on it.
Is it the duplicate mail messages bugging you? I would like to stop that but I’m seeing a big take up in audio and about 2/3rds are using the substack web/app to listen and so the only way they find out about a new audio drop is generally by email (unless they have notifications on). I’m working on it. I didn’t want to do two emails.
I'm loving Substack. They make it so easy to publish and distribute content.
I treat my podcast as the audio book version of what I write. I actually write knowing a decent chunk of my most devoted subscribers will be listening. (which makes this season sometimes challenging...describing maps verbally!)
But last week I was crunched for time and really wanted to just publish the text to hit my Friday deadline and then use Saturday to produce the audio version (I accidently deleted chunks of my audio editing). Readers would get it delivered on Friday, but those subscribing through their podcast service (one of my favorite features of Substack) would get it on Saturday....if Substack allowed this model. Instead I just pushed through and posted them both as one later than expected on Friday.
As a reader, I do find it cumbersome to get two emails with the same title and the same content...but I feel your pane on negotiating these two mediums.
Oh I see. Tricky!!