How to design flexible software
We previously held a fishbowl about how to design to avoid configuration. But when you can't avoid configuration, how do you do it well? And if we want our software to be flexible, what other options do we have besides configuration? What other ways are there to make software flexible?
This is a
fishbowl: a panel conversation held on the Handmade Network Discord where a select few participants discuss a topic in depth. We host them on a regular basis, so if you want to catch the next one,
join the Discord!
bvisness
Topic: How to design flexible software
We all want software to be flexible. We want it to work for lots of different users, we want it to adapt to different workflows. We had a fishbowl about how to design to avoid configuration, and you should read it. But when you can't avoid configuration, how do you do it well?
And furthermore, if we want our software to be flexible, for users to be able to adapt it to their needs, what options do we have besides configuration? What other ways are there to make software flexible?
And what about extending software? Flexibility is one thing, but some software can be customized so far that it's practically a new program. To what extent is this desirable? And how do we design these extension systems well?
There's lot of topics we could potentially discuss. But let me start by introducing our participants today:
@Allen4th, creator of 4coder and member of the Dion team working on future programming systems
@demetrispanos, esteemed community member, PhD, wise person and key contributor to our last fishbowl about config
@nakst, creator of the Essence operating system and many lovely tools
To give a quick summary of what we discussed at the config fishbowl, we had a couple key insights:
First of all, Demetri laid out some definitions of config so that we could identify it in our designs - for example, config is usually changed infrequently, it's not the primary kind of data that the program works with, etc.
But most importantly we discussed the importance of having a strong design for your software that communicates how it is meant to be used. There are many cases where flexibility is pointless and just adds a burden for your users.
But there are places where options matter, where users should be able to customize things, and we want to do that well too.
@Allen4th do you mind if I kick things off with some questions for you?
actually let me perhaps start with a more general question
sorry 
1
For anyone here - what are some examples of programs that you think do customization well? Or do customization poorly?
(btw, audience, please do chat in #fishbowl-audience if you have any thoughts - we'll be paying attention to that throughout)
at the risk of raising some eyebrows, I think it's hard to argue against the success of wordpress
2
empirically it has allowed an enormous population of people without especially technical skills to create a wide variety of experiences
though, of course, you have to distinguish the wordpress plugin authors (developers) from the wordpress administrators (often non-developers who just mix and match plugins)
that is an important distinction that I want to make as we go along
definitely something that came up as I was prepping
what about wordpress do you think makes it more successful than its competitors?
well it's been around so long that it's hard to know what competitors to use as a comparison :P
as background, I think we can probably agree that the wordpress plugin universe is seen by many as a wild west situation, where many things are done in questionable ways
I think that's likely also a source of its strength
certainly I've been hearing about how unprincipled/disorganized/etc. WP is for ... 15 years?
but the people who make those criticisms don't seem to have a principled/organized thing that is anywhere close to matching WP's success
so maybe I'll summarize this point by saying that if you plan to be broadly extensible for a large audience, you may have to accept that your software will begin to resemble the full spectrum of humanity, from the least to most appealing :)
or to put it more concretely, I think if you have strong opinions about what extensions can and can't do then you are necessarily also picking your audience in the process
I think plugins are just one aspect of WordPress's success too...the fundamental structure is pretty flexible. Like it appears to be just for simple blogs and websites, and yet the same basic structure can be turned into all kinds of websites with only minimal themeing.
a few years ago we wanted to build a new help center at work, and we evaluated many (like 20+) turnkey help center / support site products
and ultimately just settled on wordpress with a custom theme
so thank you for bringing up this example, it's a good one to keep in mind
I'll throw in two others with similar levels of empirical success, if in narrower ways: photoshop, and digital audio workstations (DAWs) like Reason, Ableton, etc.
Plugins in DAWs are pretty interesting in that the DAW treats them a lot like a black box. Take a synthesizer plugin: as input, it gets a feed of MIDI events, and a HWND to attach its user interface to, and as output it produces a stream of samples. And as long as it supports that interface, the plugin can do pretty much anything it wants! And it often leads plugins to feel like their own little environment separate from the DAW itself.
(edited)
So much so, that some of the more complex plugins end up recreating features of the DAW within the plugin itself. For example, it's common to see some synthesizers now incorporating step sequencers or piano rolls to provide MIDI data for themselves, rather than relying on the DAW to provide it.
interesting, so the DAW is a little application platform unto itself
@demetrispanos is that the aspect that you were thinking about when you mentioned DAWs?
or is there another aspect of flexibility that you were thinking of
I'd say that plus the composition capabilities
composition in the putting-modules-together sense, not the putting notes on a sheet sense
right, different modules compose with each other
I know that composition is a thing that @Allen4th has talked about oh yep he's typing now 
Mhm. So something I learned from 4coder is to think about "customization" systems on a spectrum based on the amount of control handed to the customizer.
The reason to think about that spectrum is to learn the pros and cons associated with moving more towards control on the plugin/custom code side vs control on the centralized side, so that if you're not getting something that feels like what you want you can figure out which direction you probably want to be moving.
In 4coder the customization was pushing towards the message to the customizer being "you can do anything you want you have complete control" - in fact I took that to such an extreme that I didn't even have a plugin system. There's just one customization at a time.
The advantage to that is the obvious one - your system can now be more things to more people (if they're willing to write the customizations).
The disadvantage is it reduces the ability of things to compose together. Composition is made possible by the centralized side making key decisions first.
It surprised me the extent to which Ryan's custom layer almost became the de-facto standard for a lot of people's customizations. Although 4coder provides a reasonably minimal starting off point, allowing the user to develop there own customizations in whatever way they want, most people just ended up someone else's custom layer that makes a bunch of decisions for them.
Yeah - @Allen4th would you say that 4coder's customization design achieved the goals you had for it? If you were to design it again, is there anything you would do differently?
(edited)
It definitely did achieve the goal, which was that 4coder could operate as a starting off point for an editor which could then be made into just about anything. But I would do it quite differently, because I'm not convinced that's a very useful goal anymore.
If a customization system is "you can do anything the C language could do" then yes they can make it into whatever it is they need, but if they can program C, they can already make whatever they need. Shipping something to someone should probably be about saying "I've gone and done a lot of the exploration through the things you could do, and I think this is a pretty good set of decisions". I would probably focus a lot more on a restricted customization system where you can piece together pre-fabbed bits if that's all you need, which is currently not an option in 4coder really.
Sure, that makes sense - and in fact I think that falls in line with what we discussed in our config fishbowl
it's "powerful" in some sense to be able to do anything, but the software needs to actually solve some problems for the user too and make it easier for them to achieve their goals
Right. I think as another point we're assuming "software" here means end user software. But really if you want to leave all the power in the user's hands, I think a library is more of an appropriate structure.
This was one of the big Data Desk -> Metadesk changes Ryan and I did. Data Desk was modeled after 4coder's one-customization approach. But the same thing as a library turns out to make a lot more sense.
Mm, I see. Since it's explicitly designed to give all the power to a programmer, you allow their code to have primary control.
But as @nakst mentioned, it seems that not many people have really gone to that extent with 4coder. It seems like a most users aren't actually interested in doing that much work. So I'm curious how we start to shift toward the centralized control side in a way that works well.
if @rxi is around, lite's plugin system could be an interesting counterpoint
otherwise we could start to discuss wordpress plugins in more detail since @Rudy was bringing up aspects of that in #fishbowl-audience
(plugins in general are a pretty rich vein)
I was mostly providing supporting arguments for the point Demetri had initially made
As it pertains to WordPress specifically since I have a looooooong history with the software
pulling in the point from the audience channel, I think the spectrum of contributors (core developers, plugin creators, people who arrange plugins) seems an important architectural feature
(context: Rudy works for Automattic, the creators of WordPress - and perhaps has history with WordPress before that?)
not in core development but as a freelance developer
sort of the community i was thinking about in that point
because there are multiple target audiences in that software
there is the development community: making WordPress for developers to use
there are the site admins: making WordPress easy for them to use (the non programming aspects)
then the end end users, or people that visit WordPress sites
and there are levels in between all that, for example theme shops
another common theme I note here among WP, DAW, Photoshop: these are all content systems of one form or another
I was trying to figure out an example of similar extensibility success that wasn't itself a content system and the first thing that came to mind was web servers (starting with apache's mod_foo architecture)
I consider the web server example much more limited compared to the others but I wonder if others have better examples
@Voran mentions game modding
1
bvisness
But as @nakst mentioned, it seems that not many people have really gone to that extent with 4coder. It seems like a most users aren't actually interested in doing that much work. So I'm curious how we start to shift toward the centralized control side in a way that works well.
This is something I've been thinking about with Essence: how much of the system internals should be exposed by the API for applications to customize on behalf of the user? Should it be possible to say, install an application that changes how the native GUI textbox works? There seem to be a lot of disadvantages to doing so. Firstly, there is the concern of how inter-plugin interactions will behave, and what will happen when the system internals are changed, that you can see examples of discussed on The Old New Thing blog, and I recall were also discussed in Allen's HmN podcast wrt 4coder. Secondly, the experience of using a plugin will often be inferior to if the functionality it provides were integrated directly in the core system; and since Essence is open source, if there were a really good plugin that replaced some functionality for the better -- surely it would be better to just make those features part of the operating system in the first place! And finally, there is the matter discussed just above, that a lot of people don't really want to customize their applications or system; they just want it to work!
But on the contrary, purposefully restricting the capabilities of applications seems almost antithetical to the philosophy of an operating system, in that it is meant to assist the creation of, and expand the possibilities of applications!
nakst
This is something I've been thinking about with Essence: how much of the system internals should be exposed by the API for applications to customize on behalf of the user? Should it be possible to say, install an application that changes how the native GUI textbox works? There seem to be a lot of disadvantages to doing so. Firstly, there is the concern of how inter-plugin interactions will behave, and what will happen when the system internals are changed, that you can see examples of discussed on The Old New Thing blog, and I recall were also discussed in Allen's HmN podcast wrt 4coder. Secondly, the experience of using a plugin will often be inferior to if the functionality it provides were integrated directly in the core system; and since Essence is open source, if there were a really good plugin that replaced some functionality for the better -- surely it would be better to just make those features part of the operating system in the first place! And finally, there is the matter discussed just above, that a lot of people don't really want to customize their applications or system; they just want it to work!
this is precisely where i think WordPress is a good model to follow
you never modify core directly but you allow actions or filters to change the behavior after the fact
in really any way they please
so in Essence's case when you make OS Updates it never breaks their system
it might just break their plugins but not the core OS
Rudy
you never modify core directly but you allow actions or filters to change the behavior after the fact
Could you explain how this works in more detail? I have not used WordPress before at all
If there’s one cardinal rule in WordPress development, it’s this: Don’t touch WordPress core. This means that you don’t edit core WordPress files to add functionality to your site. This is because WordPress overwrites core files with each update. Any functionality you want to add or modify should be done using plugins.
Plugins allow you to greatly extend the functionality of WordPress without touching WordPress core itself.
one important thing to note here is you can touch core, as in there is not restricted access....
which is something that would be nice to see in an OS
but important to let folks know at every turn that they modify core at their own peril
I'd also love an elaboration on the idea of WordPress actions/filters changing behavior, and the "don't modify the core" philosophy. I am a terrible web programmer, and was quite young, but I worked in WordPress for a time and my feeling was always that I had a lot of confusion resulting from the order of plugin installation & precedence. To me it's exactly the text box problem that @nakst described. How do you deal with it when two plugins both have something to say about a systemic thing, and who goes first/gets control makes a big difference?
@Allen4th without turning this discussion too WordPress specific I would encourage anyone interested in these questions to take a look at the developer / plugin handbook it is not too involved of a read https://developer.wordpress.org/plugins/intro/
At a high level it's certainly the case that WordPress provides a lot of "hooks" where people can register callbacks and such
plus various APIs for saving and loading data, checking user permissions, tons of general stuff for accessing content in the system
I wouldn't say plugins are particularly "sandboxed"
I know that some hooks do have priority, where you specify a number to help WP sort out what goes first...it can definitely be a pain point.
Although most plugins work independently from each other.
I like to think of systems like WP's as "board game rules" where there's a fixed sequence of operations that everyone can know. This means that non-developers can say "ok step 4 is rendering the page header, after that happens we need to do auth verification before step 5 which is rendering the navigation bar"
and then WP actions/filters etc. provide ways for plugins to interpose on those "board game rules"
1
bvisness
Although most plugins work independently from each other.
plugin conflicts are very much a thing, unfortunately
especially when you have millions of developers and many of them not thinking about how theirs might interact with anothers
Rudy
@Voran mentions game modding
So, about modding, I guess what I'm most curious about is how a game creator who wants to allow modding should approach it. I've seen a lot of approaches.
Minecraft, as the biggest example, started out without mod support, but was easily able to be modded because it was made in java and the jar file was easily modified. In recent years, another method of user-side configuration which is extremely similar to mods is that of Datapacks, which allows you to change the input data to the game (but not add additional functionality in the way that mods do). Other games actively support modding, with examples such as Starbound using Lua or Space Engineers using C#. So there seem to be a lot of ways that people have approached mods.
But while the desire for players to add to the game seems to be there, from both developers and their communities, I've noticed that a lot of games which are designed to be modded fall short of the mark. It's certainly difficult to mod compiled games in languages like C++, especially without the source code, but it also opens up avenues of modding that typical modding apis don't actually present, because they effectively modify the game that's running rather than just providing a bunch of input. So the best situations for modding end up being those like minecraft, where nobody put any effort into making the game extensible, but the game is easy enough to modify due to the structure of how it was built.
So I'm wondering what ways people would approach the problem of trying to make a game which is compiled in a language like C++, but also able to be modified in ways which are mutually compatible between different mods, and powerful enough to support game-changing behaviors that don't require the game author to anticipate everything that people might want to do.
nobody put any effort into making the game extensible, but the game is easy enough to modify due to the structure of how it was built
I think the idea of modding is probably outside of the scope of this conversation to an extent, because what you describe as being most effective is something that you wouldn't expect most people to do.
Right, I suppose it's a bit of a different challenge there
But it's weird that the most effective thing is so difficult.
(edited)
It's really strange to me too, and it's what I think a lot about when it comes to mods. Java isn't good, in my opinion, but because it's easy to open it up and just slot something in place of an existing piece of code, modding just works (more or less; it took a lot of work for minecraft mods to get to where they are today).
One of the things I was thinking about as I prepped for this fishbowl is what "interfaces" or "surfaces" your software has for customization. And I think we've listed many over the course of this conversation so far, each pertaining to different users:
- Extremely low-level, modifying the executable itself with no explicit interface (e.g. minecraft mods, hardcore developers only)
- A library with which you can do nearly anything (e.g. 4coder, experienced developers)
(edited)
- A plugin system with "hooks" where you can modify aspects of an established experience (e.g. WordPress plugins, developers only, but open to more casual use)
- A flexible system that you use without extension (e.g. WordPress posts and pages, any user)
(edited)
Many highly customizable programs seem to have multiple of these, and they target different types of users.
(edited)
I think that expresses pretty well the spectrum I tried to point out earlier. I think a key idea I would want to pass on is that just because the higher level things can be built from the lower level things in theory, that doesn't mean that only providing the low level things is good enough. The design work you put into higher level things pays off separately even if you leave room open for those lower level customization routes.
That's a good point. Having greater customization capabilities like in 4coder increases what you can do, and having higher level abstractions that non-programmers can use increases who can do things, and with both paths open, you kind of get both things.
An interesting distinction though is that in something like WordPress, developers are primarily making tools for end users. Whereas with something like 4coder there isn't really any end user beyond the developer.
This is not unique to 4coder either; I see it in a lot of programming tools
(edited)
I also think it pays off in the compositional side. If all customization is low level you don't get composition of independent modules. So even a really skilled programmer can't do anything about it, if the centralized side didn't do any high level designs to enable composition.
bvisness
An interesting distinction though is that in something like WordPress, developers are primarily making tools for end users. Whereas with something like 4coder there isn't really any end user beyond the developer.
Not sure id agree with that, depending on the definition of end user
well, people downstream of the developers
It's interesting to me how different examples we've seen here today handle composition differently
Allen, you discussed 4coder, and Rudy brought up WordPress, and they both seem to have conflict situations
Demetri brought up DAWs, which seem to naturally compose plugins because each just produces an audio track (?)
and the whole point of a DAW is to compose audio
you can still get conflicts with poorly written plugins but less so, yeah
I think an interesting dimension of this problem is how much work to prevent conflicts is worth it. There's at least three levels:
1. I didn't even do work in the core that would make it possible to avoid this conflict
2. I made it possible to avoid the conflict if the plugin behaves, but an "antagonistic" plugin can cause conflicts
3. I have defended against bad plugins so that it's not possible for a bad plugin to bring down the system
And by definition, each of those constrains what you can actually do a little bit more than the last
(edited)
definitely seems like if you're going to add plugins or "extensions" to your software, you should be considering conflicts from the start
and probably considering ways of designing things to avoid conflicts in the first place
That's all assuming you want to do that kind of customization though. And I'm not even completely convinced that that should be our focus.
Maybe as programmers it's natural for us to gravitate toward making these platforms for plugins and customization, but how important is that actually?
Maybe it's very important; Demetri opened with WordPress and it's fair to say that its success is largely due to extensibility
but is that the primary factor?
I think this connects back to the observation that most of these systems are in some way linked to making content
1
1
and naturally, there will be an enormous variety in what people will want that content to be ... too much variety for a developer to anticipate and plan for
can you think of an example of a system that isn't for "making content"? seems like most software is about "making content" in some way
a highly extensible system? the best example I have is things like web servers or programmable routers
I'm interested in both extensibility and general flexibility
Making content that other people can use creates a market, which I think Demitri mentioned earlier in #fishbowl-audience .
extensibility seems to be a good way to ensure flexibility long into the future, as long as there are people willing to extend it
I'm just not sure that we should all be thinking about plugin systems all the time
I'm open to the idea for sure, but I'm not sure I have a good example?
One fun thing that nakst mentioned before the fishbowl is how even simple things like resizing a window can be considered "customizing" the user's experience to some extent
and there is some real truth to that because I can't open this thread in a separate window to view it alongside the audience conversation 
we wouldn't typically consider that "programming", but it is providing some affordances to the user that allow them to adapt the program to their own workflows
this is perhaps the end-end-user use case
(edited)
but it's also something that is generally far more in the author's control, even in software that might have plugins and high levels of extensibility
Aha, perfect time to bring up this screenshot
How ironic it is that a dialog box designed for customization of the system cannot be customized in such a simple way -- making the window bigger
The window size thing is in fact interesting. We discussed earlier how some games seem to do a really good job at something like plugins (mods in the case of games) but something common among games is very restricted screen resolutions.
The constraint of design where the canvas width/height are variables sometimes works and sometimes doesn't.
Not sure what the lesson is, it's just interesting that something can be highly customizable along a fairly rich axis and then totally locked down along such a simple axis.
I think discussing user interfaces of software is quite relevant to all this. One thing that is commonly brought up as an argument in favour of command line tools is that it is often very simple to compose ("pipe") applications to achieve a greater purpose. But with graphical user interfaces the axis of flexibility is quite different: instead the user is treated to things like customizable keyboard shortcuts, or customizable toolbars, menus, etc.
(edited)
There is a lot more flexibility within a single application, rather than flexibility in the connections between applications.
The ability for an application's data to connect with other applications is pretty big as well though - it makes the application much more flexible in terms of workflows that use it
in GUI software you see it more with copy-paste
That's interesting, and I was actually pondering browser extensions as I prepped for this too. That's a world where lots of things are possible because applications use a common document structure.
Seems like a similar thing.
bvisness
The ability for an application's data to connect with other applications is pretty big as well though - it makes the application much more flexible in terms of workflows that use it
This is why data formats are key - deeply flexible software is made possible by having input/output data that is well defined and commonly used.
1
nakst
I think discussing user interfaces of software is quite relevant to all this. One thing that is commonly brought up as an argument in favour of command line tools is that it is often very simple to compose ("pipe") applications to achieve a greater purpose. But with graphical user interfaces the axis of flexibility is quite different: instead the user is treated to things like customizable keyboard shortcuts, or customizable toolbars, menus, etc.
(edited)
You mention customizable keyboard shortcuts, toolbars, menus, but those are actually quite rare these days
I plan to make those standard features for all native Essence applications :)
it seems like it used to be the expectation, and to some extent the norm, that you could customize those things
(edited)
Another idea I had was: imagine if you could drag a Lua script into the toolbar of an application, and when you click it, it is able to automate the UI of that application through a standard interface. But then I realized that this is basically what browser bookmarklets are!
This is similar, but different to browser extensions; browser extensions are expected to sit in the background silently changing some aspect of the web experience, but bookmarklets are like a button that the user owns and can call upon to perform a specific custom action as needed.
Well and what makes the bookmarklet possible is that the presented structure of the UI is actually another "interface" for things to connect with
there should be a key on everyone's keyboard that is dedicated to calling up a little program that you maintain yourself
I really like the concept of the user having their own buttons in a toolbar, or their own keys on a keyboard.
It's a much more richer way of the user expanding their software and their workflow, than enabling plugins that run in the background.
(Sorry for going on a bit of a UX tangent, there 
)
that's the whole reason we do these fishbowls
I like the "scriptlet-as-primitive" idea a lot
so then each Essence app would expose some data structure (including functions) to the OS as scriptable
and you just drag a lua script onto the application window, the OS does the rest
1
demetrispanos
so then each Essence app would expose some data structure (including functions) to the OS as scriptable
it seems though like much of the power of that comes from ambient things about the app, and not extra work on the developer's part
Apple has had their Automator thing forever and it never seems to get much use or support
1
they have Shortcuts on iOS now with seemingly similar results, although they made the smart decision to hook into the share sheet system
nakst
I really like the concept of the user having their own buttons in a toolbar, or their own keys on a keyboard.
how would you consider this to be different from apple's touchbar?
and 90% of people disliked the touchbar
Rudy
how would you consider this to be different from apple's touchbar?
I was under the impression that the contents of the touchbar were primarily restricted by the application developer?
that was my understanding as well
nakst
I was under the impression that the contents of the touchbar were primarily restricted by the application developer?
i believe there were tools available to customize the bars to run any application or macro of your choosing
i had a co-worker i saw do this
it seems to me like you need some kind of standard structure that the application already uses, that people can hook into and use for themselves
for browser extensions it would be the DOM, for windows I guess it's something something XML
what's interesting to me is that a lot of these user-facing things like toolbars and whatnot seem pretty orthogonal to other aspects of customization
like an app can have a plugin system, but if the platform provides custom toolbars, then that's just another way for the app (and any plugins) to present themselves
Allen4th
This is why data formats are key - deeply flexible software is made possible by having input/output data that is well defined and commonly used.
Since you're working on Dion, could you explain some of the reasons why it can be important to have a common data format to share across different domains?
going back to those layers / interfaces I was talking about before, apps and platforms provide interfaces at all levels - toolbars and windows for the end-est users, options and config for power users, plugin systems for developers
maybe if you want to make really flexible software, you just need to think about providing specific affordances at all levels
(did we lose allen for now)
bvisness
maybe if you want to make really flexible software, you just need to think about providing specific affordances at all levels
Kind of like how Windows has the control panel for the end-user settings, and then the registry for more power user stuff.
But once you get to levels like the registry, you then start having to share the space with applications storing internal persistent state, which were never intended to be modified by a human.
Which is a little different to the Unix philosophy, where everything in /etc is theoretically up for the user to configure.
yeah, and that certainly gets weird
and none of that is probably what people would consider a good design practice these days, as we move toward applications being less trusted
although obviously apps could have their own isolated "registries" and still have the same problems, I suppose
Since this has been going for nearly 2.5 hours now, I feel we should start considering some more concrete takeaways
we've certainly covered a lot and if possible I'd like to try and synthesize a few points
are there any main points that jump out to any of you? otherwise I have some ideas for how we might go ahead
There are obviously lots of ways you can make your software "flexible" - from resizing windows all the way down to heavy modification of the system
I don't know that we can prescribe any of them; it seems like that will depend heavily on the specific program
(edited)
but assuming you want to provide flexibility for a certain type of user - what are some specific things we can consider?
like for example if I want to provide a platform for developers to extend my software in the future
what should I be thinking about?
Okay, sorry for the blip there I can try to answer that question if you'd still like to go down that road.
by all means go down that road
It's a bit of a hard topic to unpack in a short way. One angle is that I think looking at things in terms of data formats/types and the arrows that transform data or transport that data is a more first-principles approach. And there's plenty of flexibility to software viewed from the lens without ever having to talk about plugins or customizations.
Another angle is to take a look at how a "plugin" interacts with the core, or how they interact with other plugins, and see that really what they're doing is bringing in new "arrows" to the program. The reason they can't just be separate programs is because the cost of serializing and communicating data would be prohibitive.
So a plugin is what you get when you want to take an arrow that already exists, and compose it with another arrow, but also need to optimize the flow of arranging that composition.
...we might need a drawing for this
I think it's worth bringing up because it can sometimes be tempting to overcomplicate things. For instance does an image editor need a plugin that could actually just be a different image editor? If they can both load and save the same file what's the difference?
In that case the difference is that the standard formats for images generally are too underpowered. If you want to preserve layers, the issue is each editor has it's own format for that feature.
If a format existed for images with named RGBA layers, could you get closer to composing all the capabilities of two different image editors without them needing to "plug together" at all?
Like I said, hard to unpack, maybe that did the trick, maybe it didn't but I think that's the best version of that idea that I have in me right now.
Sure, so in the case of programs that work with images, the lack of a common acceptable format makes it difficult for these programs to exist separately, and instead you're incentivized to make one a "plugin" for the other?
Right. Basically a plugin "is" a program. I think @nakst could chime in to tell me if this perspective really makes sense. But I tend to see an OS as: a program that knows how hardware works and has a strong plugin system - those plugins are the userspace applications.
1
i could see that as an effectual metaphor 
In the same way a plugin to Paint .NET is like a "program" of the flavor defined by Paint .NET. Those programs get invoked when I hit a button in the toolbar, and they have access to the API provided by Paint .NET. By exchanging data through an API instead of through a format, Paint .NET gets an extra layer of abstraction. They can change their internal data structures as long as the APIs still work in equivalent ways. But the downside is now the only programs that can work with their layer format are the ones written to their API. If you make a really robust data format definition, then the user space applications can cooperate just through the standard APIs of an OS.
Have we touched on the idea that flexibility in software tends to be a shift of the burden of correctly designing the software from the developer onto the user? (sorry, got here a bit late)
I don't think we really have
To some extent that was one of the takeaways of the config fishbowl, but we haven't touched on it much here today
and I'm curious how you apply that idea to your own work
rxi
Have we touched on the idea that flexibility in software tends to be a shift of the burden of correctly designing the software from the developer onto the user? (sorry, got here a bit late)
this was indeed my original thesis on the previous fishbowl about "configuration", that it is usually an excuse to avoid design responsibility
ah. I started typing some stuff but it sounds like it might have all been covered in that discussion in that case 
I don't want to end up rehashing it all
no we haven't touched this much yet
except in discussing how extensibility in DAWs etc. is essential because of the sheer range of things people might want to do, which is impossible for a single design to cover
so in some sense it's a question of whether it is possible/good for the designer to take the responsibility or not
to pick one specific project of yours - how would you say that idea shows up in the design of lite?
interestingly not so much in lite, such that it relinquishes almost all the responsibility of choice onto the user (though does try to enforce a deliberate philosophy) but in this context the user would typically be a software developer so it's a little different to if it was something like a piece of photo editing software. I view lite as something akin to a large python script; it's meant to be something you modify quickly and without too much concern and if things break hopefully the whole thing is small enough that you'd have a good understanding of why -- the plugin system is based around simply monkey patching lua functions of which the editor's core is built from (with exception of the lower-level rendering and I/O stuff)
this would be at the end of the spectrum closer to complete flexibility which at its most extreme would be a C compiler paired with a text editor, where you'd have flexibility to the point of being able to write any software. I think it's important to consider the faults of this freedom when considering flexibility at all, as presumably the faults of the extremity would apply to anything though to a much lesser extent
I think, perhaps, there's a difference here between neglecting design responsibility vs it being out of scope
1
for example if I make a spreadsheet program for you, whether or not you make good financial decisions with it is out of scope
I'm not leaving a "hole" in my design for you to fill, I'm just filling a portion of the space
whereas if I make an application UI with a bunch of widgets and I don't try to reason about how those widgets should be laid out, then I am leaving a "hole" in my design
I enclosed the space of "there are widgets laid out somehow" but refused to put order into that space
possibly because I thought "the user will configure it as they see fit"
Sure; one is clearly the domain of the program and one is not
What value is it to a user to decide how widgets are laid out? That’s not the point
to flip this framing around, you could then think about extensibility as how the designer sets the stage for downstream design decisions
I did A and B, which means you can do C and D (that build on, but don't overlap A and B)
demetrispanos
whereas if I make an application UI with a bunch of widgets and I don't try to reason about how those widgets should be laid out, then I am leaving a "hole" in my design
can't it be unclear where that line is? Even with this example it is a user choice in a lot of software -- eg. being able to rearrange the panels in photoshop, or re-order the columns on the list view of the task manager. Should I be allowing the user to change the UI to that degree?
the user can re-arrange photoshop, but photoshop has a set of initial opinions
You're allowing users to make design decisions, but these are design decisions that you've already made and implemented a default for. Because the premise of Photoshop is not rearranging the panes, but editing images, the ability to edit positions of things is not the thing that you should be delegating purely to the user.
So my line would be where the purpose of what you're providing is the ability to change something, it is not important to make a default decision, but for something which is an addition to the thing you're providing, you need to provide a default decision even if you allow people to make their own decision in that space
demetrispanos
the user can re-arrange photoshop, but photoshop has a set of initial opinions
that it can be changed from the default changes the default itself, though. How much thought and time and research was put into the default configuration? If I open photoshop and move a panel somewhere because it's what I was used to in paint.net, though this was an initial convenience this could end up being detrimental in the long term to the general workflow. This feels in general an issue with flexibility; in that the user might be too eager to change things rather than getting used to the defaults, and presumably there was a good reason those defaults were picked
rxi
that it can be changed from the default changes the default itself, though. How much thought and time and research was put into the default configuration? If I open photoshop and move a panel somewhere because it's what I was used to in paint.net, though this was an initial convenience this could end up being detrimental in the long term to the general workflow. This feels in general an issue with flexibility; in that the user might be too eager to change things rather than getting used to the defaults, and presumably there was a good reason those defaults were picked
I agree that when you add flexibility you add the temptation to do "noise" edits
pointless micro-changes that make your setup non-standard but not any more useful to you
with great power, great responsibility etc.
As a counterpoint to the users shooting themselves in the foot, sometimes the user knows better than the developer what is most effective for them; to use the aforementioned comparison of user-space programs as 'plugins' for an OS, it's very unlikely that the OS is going to provide defaults that are perfect for everyone.
(edited)
demetrispanos
pointless micro-changes that make your setup non-standard but not any more useful to you
I feel there are ways you can constrain this with e.g window docking, tabs, that kind of thing. I’ve seen some apps that seem to have a full internal window system for no reason, but there’s a middle ground.
But at the same time it may just be noise.
yeah, you may have heard me talk about a design being "floppy" before
that is, there is too much granularity of choice relative to granularity of utility
my common example, which related to flexibility, is web page layout
it makes 100% sense to have accommodation for widescreen, common desktop width, common tablet width, common phone width, and then some extreme fallback
it makes (IMO) 0 sense to have continuously-variable adaptation
similarly, moving your UI panes around makes a lot of sense, but having pixel-level precision of where you place them does not
there's no plausible reason to have something almost docked but still 1-2px off being docked
so I think there's a lot of value in reducing the complexity of the input space down until it resembles the granularity of the utility you get out of changes
1
I do want to highlight a point rxi mentioned, which is that users may just want to change things right away instead of learning
Which is at least a strong factor to keep in mind when designing stuff, because I know that impulse
and actually we could apply this lesson about "floppiness" back to lower levels of the software too
for example, if designing a plugin interface, how granular does your interface need to be
allowing things to be too granular may just be poor utility for users
that may apply to what Allen was saying about 4coder, and how 4coder being an "editor template" is just not that useful a goal.
yeah 4coder gives you extreme/unlimited granularity in what you can do, which is both a strength and a barrier to entry
the more granular a decision you require from your user, the fewer people will be able to even express that input never mind make the choice wisely
well, as long as you're aware of that tradeoff, hopefully you can make a smart decision about what is best for your software
in keeping with the advice from the config fishbowl though, maybe it's best to start more opinionated and relax it later.
yes this connects to what I was saying earlier about "board game rules"
a common reference point that, maybe, nobody actually uses in practice ... but it is the reference point from which everything else is expressed
"I use XYZ but instead of rule R I use rule Q"
as opposed to a blank board, a marker, and a bunch of generic pawns?
right exactly, as opposed to a complete vacuum
"You can invent millions of games with this!"
that makes a lot of sense, and I always like to have more analogies
I know it sounds like a stretch, but really the soren johnson talk about board games I posted in -audience channel is relevant
actually could connect to the points about modding too, oh boy
and we all know the concept of "house rules" for board/card games
"in this house, we play monopoly with free parking money"
not actually a rule, but a very widely used modification
we do see lots of great game ideas starting as mods instead of stuff from scratch... 
now I'm getting way off track
I don't know if it's really that far off track
WP never set out to make a help desk system, and yet you made it one
and a better one than the turnkey ones in fact
well Boy Is That Interesting
I guess WP did start out with a heavier emphasis on blogs and then morphed into the more general system it is today, without losing that core idea of a blog
(edited)
1
I think mods start to turn into games when the author no longer associates the mod with the base game it was originally associated with; I've usually seen this happen in cases where the base game isn't able to live up to what the mod's idea can deliver, and when the mod author has enough support to their idea to make the move to separate it. Which I think makes the point that it can be pretty important what you deliver as a baseline in an extensible program
yeah, but the game still serves as an important starting point even if it was never really intended to be modded
maybe we can dig into this more elsewhere but we are nearly at the 4-hour mark (!) and I think we should try to respect everyone's time and wrap up
so - what do we think are some takeaways from all this?
For one, I think we have a re-affirmation that design is important and you should consider what flexibility is valuable to your users.
I like Demetri's analogy of "holes" in the design - what space do we expect users to fill, and what is reasonable to expect
I think the idea of the spectrum I brought up initially ended up even more reinforced by several of the other ideas we discussed. The low level vs high level interfaces, & the issues regarding handling conflicts between plugins both looked to me like they also correlate to this vague notion of a gradient I already had.
I think some concrete points of advice I might choose are:
- You will likely have many different kinds of users, from developers to complete normies - consider building ways for each of them can customize their experience (and for developer systems to feed into normie systems)
- If you want to make your software extensible, strongly consider how to handle conflicts (and maybe see if you can constrain plugins to avoid conflicts)
- Don't make your software "floppy" - for any interface you build at any level, try to make decisions for those users that benefit them.
Is there anything you would add?
(surely I missed an important point from these four hours of conversation)
overlapping a bit with your points, I'd say
- keeping in mind the ecosystem/"food-chain" of extenders, as seen with WP, DAWs, Photoshop
- keeping in mind scope of responsibility, and making sure you don't leave holes within your responsibilities
- thinking about granularity of modification, from "change anything at any granularity" to "slap together some plugins"
well we have precisely nailed the 4-hour mark now so I think that is as good a time as any to call it!
Thanks so much to all the participants for another wonderful conversation! I always love being able to point back at these and find useful insights for later.
I would give my usual shtick about looking at the pinned messages, but if you're reading this, you already know how that works :)
Thanks all for following along, and if you want to continue the conversation, please continue in #fishbowl-audience or any of the other channels!
2
