5 ms·

Thank you, that's what I was trying to say. I'd argue that 95% of all Word users only use a tiny fraction of what the product can do and if they had just writte

Thank you, that's what I was trying to say. I'd argue that 95% of all Word users only use a tiny fraction of what the product can do and if they had just written that part, it wouldn't need to be that insane amount of code. Even if you added all the network features...etc to their Smalltalk machine, I bet they would've done it with less code than MSWord, not to mention the size of the rest of Windows which is insane. I think his point might have been that society is on this path with ridiculous software size, complexity, bloat...etc. This software is enormously difficult to maintain, impossible to rewrite, and too hard for even a group of people to understand. Kay's talks are on YouTube and definitely worth a go. He also posts on here sometimes I believe, so maybe he will correct my assumptions.

Qwertious 9y ago
>I'd argue that 95% of all Word users only use a tiny fraction of what the product can do and if they had just written that part, it wouldn't need to be that insane amount of code. Problem is, they use different tiny fractions.
com2kid 9y ago
> I'd argue that 95% of all Word users only use a tiny fraction of what the product can do and if they had just written that part, it wouldn't need to be that insane amount of code. I think you'd be surprised. Insert a graph into Word, now all of a sudden you need OLE so that when the underlying data changes the graph is automatically updated, axis are renumbered properly, the legend is in place, etc. Insert a picture. Now it needs a caption. How does that picture flow with the rest of the text? Just looking at the "Insert" tab in Word, I've used: 1. Page Break 2. Cover Page 3. Tables 4. Pictures 5. Shapes. 6. Smart Art 7. Chart 8. Links 9. Bookmarks 10. Cross-references 11. Comments 12. Header, footer, page numbering 13. Drop Caps 14. Interacting with Signature Lines 15. Date & Time 16. Symbols 17. Equations That is 70% of the features of that one tab. Feature code is expensive, it costs to write, and it has a heavy cost to maintain. It rarely gets written unless there is a demonstrated customer need for it. There have been a lot of competing word processors over the years that pop up with just a minimal set of features, some of them even had Word support. These word processors end up being discarded the second someone comes across a feature it doesn't have, they need, and that Word does have. Excel is even more this way. Look at a power user of Excel, a huge % of the program is exercised on any given day. Some groups use more of the numerical abilities, but a huge number of features are going to get exercised by a user on any given day. > I think his point might have been that society is on this path with ridiculous software size, complexity, bloat...etc. Maybe. But what is bloat? Apps written in Electron are easier to maintain and update despite the underlying platform being huge. I'd say it is because Electron solves a lot of small problems for you, but perhaps it is also because people give up on some things. Electron apps don't have the theming support that Winamp did, but adding real time streaming support for audio/video takes months instead of years, and has become table stakes in the modern world instead of an amazing differentiator. I'm not really sure where I stand on all this anymore. :)
- mwcampbell 9y ago
  > Electron apps don't have the theming support that Winamp did Pardon me for answering this at length, though it's tangential. But I actually know quite a bit about Winamp. On the contrary, Electron, being based on Web technologies, offers a much better way to do theming, via CSS. Of course, most apps don't expose this capability to the user, but they could. Winamp's theming support, at least in Winamp 2, was actually very crude. A Winamp skin was just a collection of bitmap images (BMPs, I think) that made up the main Winamp window, the EQ window, and (if I remember correctly) the borders of the playlist editor and media library windows. And some windows, like the main preferences dialog and the windows opened by various plug-ins (e.g. SHOUTcast), weren't themed at all; they had a generic Windows look. And it's fortunate that the most complex parts of the Winamp UI (ignoring the media library) were not themed, because as far as I recall, Winamp never implemented proper accessibility for its custom UI. (I don't have Winamp on my current machine, so I can't easily verify that now.) The Winamp main window was completely inaccessible with a screen reader, except for the title, and I guess we wouldn't have even had that if it wasn't needed for the Windows task bar. That wasn't so bad, because every function in that window had a keyboard command, and because Winamp is an audio player, the user could usually hear the result immediately. When toggling shuffle and repeat, Winamp provided a way to get the state of those flags through a window message; I don't know if they did that for accessibility or some other reason. I don't recall if blind people had a good way to use the EQ. Perhaps they could adjust it with the keyboard and just listen to the results rather than looking at the sliders. IIRC, the playlist window didn't use a standard Windows list view for its contents, but it was still more or less accessible in practice. All actions in that window could be done with the keyboard. And it used standard GDI text rendering functions to display the contents of the playlist. All good Windows screen readers could intercept GDI function calls (or their counterparts in kernel mode) and build an "off-screen model". This was good enough for knowing what text was in a window, and which text was highlighted. So a blind user could access the playlist editor. (Note that no screen reader has attempted to do this for more advanced graphics technologies such as Direct2D and DirectWrite.) But if the rest of the UI, such as the preferences dialog and the SHOUTcast plugin windows, had been skinned... well, blind people probably wouldn't have adopted SHOUTcast so eagerly, from the day it was first released. As far as I know, no screen reader, even with an advanced off-screen model based on intercepted GDI calls, could provide good access to a fully custom UI, with buttons, text fields, combo boxes, check boxes, and so on, unless the application implements an accessibility API (for Windows, either Active Accessibility or UI Automation). In fact, the reason why Microsoft created Active Accessibility, the first accessibility API, was because they needed it for the dialogs in Office, since those dialogs use windowless controls. But, bringing this back to the original comparison with Electron, with Electron you can have an application that's both fully skinned and accessible, as long as you follow web accessibility guidelines. So keep that in mind if you're inclined to reject the bloated Electron and use (or create) your idea of the perfect, lightweight, themable GUI toolkit.
mpweiher 9y ago
> 95% of all Word users only use a tiny fraction of what the product can do Right. That was the first 100x I was talking about. It's the second 100x (well: 200x) that's the issue ;-)

Qwertious 9y ago

>I'd argue that 95% of all Word users only use a tiny fraction of what the product can do and if they had just written that part, it wouldn't need to be that insane amount of code. Problem is, they use different tiny fractions.

com2kid 9y ago

> I'd argue that 95% of all Word users only use a tiny fraction of what the product can do and if they had just written that part, it wouldn't need to be that insane amount of code. I think you'd be surprised. Insert a graph into Word, now all of a sudden you need OLE so that when the underlying data changes the graph is automatically updated, axis are renumbered properly, the legend is in place, etc. Insert a picture. Now it needs a caption. How does that picture flow with the rest of the text? Just looking at the "Insert" tab in Word, I've used: 1. Page Break 2. Cover Page 3. Tables 4. Pictures 5. Shapes. 6. Smart Art 7. Chart 8. Links 9. Bookmarks 10. Cross-references 11. Comments 12. Header, footer, page numbering 13. Drop Caps 14. Interacting with Signature Lines 15. Date & Time 16. Symbols 17. Equations That is 70% of the features of that one tab. Feature code is expensive, it costs to write, and it has a heavy cost to maintain. It rarely gets written unless there is a demonstrated customer need for it. There have been a lot of competing word processors over the years that pop up with just a minimal set of features, some of them even had Word support. These word processors end up being discarded the second someone comes across a feature it doesn't have, they need, and that Word does have. Excel is even more this way. Look at a power user of Excel, a huge % of the program is exercised on any given day. Some groups use more of the numerical abilities, but a huge number of features are going to get exercised by a user on any given day. > I think his point might have been that society is on this path with ridiculous software size, complexity, bloat...etc. Maybe. But what is bloat? Apps written in Electron are easier to maintain and update despite the underlying platform being huge. I'd say it is because Electron solves a lot of small problems for you, but perhaps it is also because people give up on some things. Electron apps don't have the theming support that Winamp did, but adding real time streaming support for audio/video takes months instead of years, and has become table stakes in the modern world instead of an amazing differentiator. I'm not really sure where I stand on all this anymore. :)

mwcampbell 9y ago
> Electron apps don't have the theming support that Winamp did Pardon me for answering this at length, though it's tangential. But I actually know quite a bit about Winamp. On the contrary, Electron, being based on Web technologies, offers a much better way to do theming, via CSS. Of course, most apps don't expose this capability to the user, but they could. Winamp's theming support, at least in Winamp 2, was actually very crude. A Winamp skin was just a collection of bitmap images (BMPs, I think) that made up the main Winamp window, the EQ window, and (if I remember correctly) the borders of the playlist editor and media library windows. And some windows, like the main preferences dialog and the windows opened by various plug-ins (e.g. SHOUTcast), weren't themed at all; they had a generic Windows look. And it's fortunate that the most complex parts of the Winamp UI (ignoring the media library) were not themed, because as far as I recall, Winamp never implemented proper accessibility for its custom UI. (I don't have Winamp on my current machine, so I can't easily verify that now.) The Winamp main window was completely inaccessible with a screen reader, except for the title, and I guess we wouldn't have even had that if it wasn't needed for the Windows task bar. That wasn't so bad, because every function in that window had a keyboard command, and because Winamp is an audio player, the user could usually hear the result immediately. When toggling shuffle and repeat, Winamp provided a way to get the state of those flags through a window message; I don't know if they did that for accessibility or some other reason. I don't recall if blind people had a good way to use the EQ. Perhaps they could adjust it with the keyboard and just listen to the results rather than looking at the sliders. IIRC, the playlist window didn't use a standard Windows list view for its contents, but it was still more or less accessible in practice. All actions in that window could be done with the keyboard. And it used standard GDI text rendering functions to display the contents of the playlist. All good Windows screen readers could intercept GDI function calls (or their counterparts in kernel mode) and build an "off-screen model". This was good enough for knowing what text was in a window, and which text was highlighted. So a blind user could access the playlist editor. (Note that no screen reader has attempted to do this for more advanced graphics technologies such as Direct2D and DirectWrite.) But if the rest of the UI, such as the preferences dialog and the SHOUTcast plugin windows, had been skinned... well, blind people probably wouldn't have adopted SHOUTcast so eagerly, from the day it was first released. As far as I know, no screen reader, even with an advanced off-screen model based on intercepted GDI calls, could provide good access to a fully custom UI, with buttons, text fields, combo boxes, check boxes, and so on, unless the application implements an accessibility API (for Windows, either Active Accessibility or UI Automation). In fact, the reason why Microsoft created Active Accessibility, the first accessibility API, was because they needed it for the dialogs in Office, since those dialogs use windowless controls. But, bringing this back to the original comparison with Electron, with Electron you can have an application that's both fully skinned and accessible, as long as you follow web accessibility guidelines. So keep that in mind if you're inclined to reject the bloated Electron and use (or create) your idea of the perfect, lightweight, themable GUI toolkit.

mpweiher 9y ago

> 95% of all Word users only use a tiny fraction of what the product can do Right. That was the first 100x I was talking about. It's the second 100x (well: 200x) that's the issue ;-)