SpaceAndModularizingWebPages
ThoughtStorms Wiki
As I write this, I have a new day job, working on a system built out of ... ahem ... (soto voice) ASP pages ...
And a right-old muddle some of those pages are, too. A mish-mash of HTML, VBScript, JavaScript and SQL queries. Of course, I like muddle. I like it when different things are mixed up together; when what looks to the naive observer like confusion is revealed as a slick, well adapted and integrated EcoSystem which works smoothly. I like symbiosis and density and FractalLoading and gnarls and knots and coupled systems.
On the other hand, and I admit that maybe this is the residual damage of a SoftwareEngineering education, I personally wouldn't have chosen to put these pages in quite such an entropic state :-) So, I'm going through ReFactoring and tidying them up a bit.
Here are a couple of thoughts.
- DecomposingByLanguageIsProbablyAModularityMistake (now has a page of it's own)
- In contrast to cities where consideration of space leads to ModularityMistakes, on a web-page, spatial modularization might make sense. Often different panels and boxes on a page are fairly independent. The menu-bar has little interaction with the query form, which has little interaction with the side-bar or the pop-ups extra controls, etc.
So, I'm currently pulling large pages apart into different files representing different spatial regions. I have also separated some language-specific stuff, like a big chunk of javascript which doesn't really belong on any particular region of the page. But this is an exception.
Right now, things seem to be working out OK.
So, take-home messages :
- In web-site design, there isn't a simple choice between a) messy / bad / lacking in modularity vs. b) properly organized, decomposition by language. There are potentially other kinds of modularity available ...
- unless you happen to be unfortunate to work in an environment which has prejudged the right modular decomposition, and enforces separation based on language.
- Spatial-regions might be better candidates for modules in many web-sites. Though I'm open to discover that this could be misleading.
- I've been working on database-backed web-sites for five years; thinking about problems caused by conventional development wisdom for three years; and obsessing about information systems and modular decomposition for about six months. And only now I put 2 + 2 together. I am slooooow!
In a sense the ability to mix HTML with code in JSP, ASP, ADP, PHP, ColdFusion etc. is part recognition of this. And one reason PerlLanguage is so good is that it allows a mix of code and large chunks of text / HTML. (PythonLanguage/Quixote too)
Maybe the idea of mixing multiple specialized views, all reduced to a single AbstractSyntaxTree (as in JackPot / IntentionalProgramming) also touches this.
Is there also a connection with LiterateProgramming and the mixture of code and commentary for future programmers?
SusanJones points out that decomposition by space was what HTML frames were intended for. Unfortunately they got a bad reputation.
I agree, though I think frames had the insoluble problem that there wasn't a single URL which could refer to the combination of components.
Counter
Of course, other forms of decomposition require polyglot programmers. Surely the obvious reason for decomposition by language is that it's easier to find a programmer with one specific language you want than with a specific combination of several. Although decomposition by language may be a ModularityMistake from the perspective of an ideal world, it's an inefficiency balanced by the greater flexibility and efficiency of finding programmers.
Also note, this objection might translate back into the urban case (ACityIsNotATree). Think about infrastructural and service requirements of types of activity. Maybe it is efficient to put all the offices in one-block and all the homes in one suburb etc. because they all consume similar services, and so there's an EconomyOfScale through providing those services in one area.
Further Observation
Actually it's very hard to avoid modularizing in the traditional way, due to CrossCutting between global properties (like function libraries and style sheets) and spatial regions. I'm finding my refactorings are tending to separate by language because of the different roles that each language plays. Yet I'm also getting the inconvenience of this. More thinking needed ...
Maybe it's as simple as this : spatial things such as nav-bars, results tables etc. modularize by space well; and non-spatial, global things like style-sheets and server-side code which sets up the parameters for the page and provides services to it, doesn't modularize by space.
Well, so far, so obvious. But the problem is that these two types of thing are very InterTwingled with each other. So trying to draw the line between "the spatial stuff" and "the non spatial stuff" is the real mistake. But it's so tempting, because within each of these regions, the logic of decomposition is different. (Possibly decomposition by language does make sense in the non-spatial.)
So it's the impedance mismatch between the two realms which forces the decomposition ... and yet ... it's still wrong.
Space, hierarchy and UI
SarahAllen argues that GUIs are inherantly hierarchical, so there are reasons for using a hierarchical file-format based on XML :
There are a few attributes of graphical user interfaces that map well to XML:
- Graphical user interfaces are inherently hierarchical *
Screen real-estate is naturally divided heirarchically. It is convenient for that heirarchy to be represented by the development environment.
...
- Graphical user interfaces require structure *
Graphical user interfaces need to be split into pieces to be manageable. XML provides a structured framework which makes its fairly easy to divide your work into bite-sized chunks. A common problem in a visual tool is that people "lose" things. It may be hard to figure out what object a script is attached to. An object that is invisible can be hard to discover or manipulate. In a system where all objects and code are encapsulated in simple text files, anything can be found. The inherent structure of an XML file helps organize an application. There are lots of visual tools that offer a tree-view of XML files which make this structure more approachable.