4 ms·

Office UI was reinvented at least one time. I remember when that god awful ribbon showed up. "In 2003, I was given the chance to lead the redesign of the most

Office UI was reinvented at least one time. I remember when that god awful ribbon showed up. "In 2003, I was given the chance to lead the redesign of the most well-known suite of productivity software in the world: Microsoft Office. "Every day, over a billion people depended on apps like Word, Excel, PowerPoint, and Outlook, so it was a daunting task. This was the first redesign in the history of Office, and the work that we did ended up shaping the standard productivity experience for the next two decades." ... https://jensenharris.com/home/office https://jensenharris.com/home/office https://jensenharris.com/home/ribbon https://jensenharris.com/home/ribbon

TeMPOraL 3y ago
That's not what I mean. The ribbon, whatever you think of it, only moved some functionality around. It didn't actually change the way old functionality worked. All the things you knew how to do, you could still do - you only had to learn their new placement.
heartbreak 3y ago
If we consider the Word 2.0 (for Windows) era as the beginning of a graphical Microsoft Office suite, then graphical Office has had the ribbon for as long as it didn’t: 16 years. I’m still waiting for people to stop complaining about it.
- ipaddr 3y ago
  That move was awful
  - oblio 3y ago
    For you.
ethbr0 3y ago
The irony is that LLMs are actually the real solution that Ribbon took an awkward half step towards -- how to quickly get to what a user actually wants to do. Originally: Taxonomically organized nested menus, culminating at a specific function or option screen Now: Usage-optimized Ribbon (aka Huffman coding for the set off all options), culminating at a specific function or option screen Future: LLM powered semantic search across all options and actions, generating the exact change you want to implement Why have an "email signature" options page at all, when an LLM can stitch together the calls required to change it, invoked directly from English text?
- mook 3y ago
  You missed Office 2000: magically disappearing menu items. It was pretty confusing.
  - ethbr0 3y ago
    Oof. I did. Ribbon felt enough like magically disappearing menu items to me.
- TeMPOraL 3y ago
  > Why have an "email signature" options page at all, when an LLM can stitch together the calls required to change it, invoked directly from English text? 10-20 years from now? Maybe. It depends on whether or not the industry will cut corners in this part of the experience. I find it hard to predict which features get polished, and which are forever left barely-functioning. Might depend on which are on "critical path" to selling subscriptions. 0-10 years from now? We'll still need the options page. "Email signature" options page provides visibility, consistency, and predictability. That is, you can see what your e-mail signatures are, you are certain those are the ones that will be used for your message, under conditions defined in the UI pane, and if you change something, you know exactly how it will affect your future e-mails. LLMs are quite good at handling input, though not yet reliable enough. However, as GUI replacement, they are ill-suited for providing output - they would be describing what the result is, whereas the GUI of today display the result directly. As the writers' adage goes, "show, don't tell". (That said, the adage is way overused in actual storytelling.)
  - ethbr0 3y ago
    In this case, the LLM isn't generating the output. It's only generating the sequence of actions to implement the user input. Think less "make a signature for me" and more "here's the signature I want to use, make it my default." Then the model would map to either Outlook / Options / Signature / fields or directly to whateverSetSignature(). From that more modest routing requirement, it seems a slam dunk for even current models (retrained to generate options paths / function calls rather than English text).
- 3y ago

TeMPOraL 3y ago

That's not what I mean. The ribbon, whatever you think of it, only moved some functionality around. It didn't actually change the way old functionality worked. All the things you knew how to do, you could still do - you only had to learn their new placement.

heartbreak 3y ago

If we consider the Word 2.0 (for Windows) era as the beginning of a graphical Microsoft Office suite, then graphical Office has had the ribbon for as long as it didn’t: 16 years. I’m still waiting for people to stop complaining about it.

ipaddr 3y ago
That move was awful
- oblio 3y ago
  For you.

ethbr0 3y ago

The irony is that LLMs are actually the real solution that Ribbon took an awkward half step towards -- how to quickly get to what a user actually wants to do. Originally: Taxonomically organized nested menus, culminating at a specific function or option screen Now: Usage-optimized Ribbon (aka Huffman coding for the set off all options), culminating at a specific function or option screen Future: LLM powered semantic search across all options and actions, generating the exact change you want to implement Why have an "email signature" options page at all, when an LLM can stitch together the calls required to change it, invoked directly from English text?

mook 3y ago
You missed Office 2000: magically disappearing menu items. It was pretty confusing.
- ethbr0 3y ago
  Oof. I did. Ribbon felt enough like magically disappearing menu items to me.
TeMPOraL 3y ago
> Why have an "email signature" options page at all, when an LLM can stitch together the calls required to change it, invoked directly from English text? 10-20 years from now? Maybe. It depends on whether or not the industry will cut corners in this part of the experience. I find it hard to predict which features get polished, and which are forever left barely-functioning. Might depend on which are on "critical path" to selling subscriptions. 0-10 years from now? We'll still need the options page. "Email signature" options page provides visibility, consistency, and predictability. That is, you can see what your e-mail signatures are, you are certain those are the ones that will be used for your message, under conditions defined in the UI pane, and if you change something, you know exactly how it will affect your future e-mails. LLMs are quite good at handling input, though not yet reliable enough. However, as GUI replacement, they are ill-suited for providing output - they would be describing what the result is, whereas the GUI of today display the result directly. As the writers' adage goes, "show, don't tell". (That said, the adage is way overused in actual storytelling.)
- ethbr0 3y ago
  In this case, the LLM isn't generating the output. It's only generating the sequence of actions to implement the user input. Think less "make a signature for me" and more "here's the signature I want to use, make it my default." Then the model would map to either Outlook / Options / Signature / fields or directly to whateverSetSignature(). From that more modest routing requirement, it seems a slam dunk for even current models (retrained to generate options paths / function calls rather than English text).
3y ago