I have found MVC to be far better than anything else I've used over the years, and whenever I hear it 'doesn't scale', I've often wondered 'what exactly are you doing?'.
I've seen a ton of web forms apps that didn't scale. I've seen a ton that did. I've seen a ton of PHP apps that didn't scale, and I've seen plenty that do just fine.
MVC as a seperation logic works great, and you should be doing it. If you are building controller actions for every single request, well, honestly, maybe you should be in another line of work.
Or the Yii framework which is just an abortion of code through and through.
MVC may be the epitome of poorly defined design patterns. It's a unicorn. No one can even tell you with certainty what a controller is, or how the hell MVC maps from a Smalltalk UI pattern to being used on a server stack. This always devolves in inane pedantic discussions. And it's too late to try to put some order in this wreck of a pattern definition, because everyone has already appropriated it for themselves and decided what it means for them.
MVC is not a pattern anymore, it's a marketing term with zero regards for correctness. It's used by framework designers to tell developers that their libraries will be familiar and easy to work with and they should totally try them out. And it's being used by that Facebook dude to agitate Rails coders and stir controversy and draw attention to their trendy new lib, and it's working flawlessly to that end. Pure marketing brilliance.
But only madness lies in the direction of trying to salvage MVC as an engineering term with any degree of correctness, and whether whatever it supposedly means is really scalable or not. It's not even worth the effort. The only lamentable consequence of the bastardization of the MVC name is that by slapping it over everything, the bulk of web devs nowadays are left with a very poor vocabulary and a very poor understanding to try to describe server architectures with.
I've discussed, or watched coworkers present, MVC as an idea many times. After they draw the three boxes and arrows on the whiteboard, they start winging it. You can tell someone to make three files for everything they do, but it's a whole different plane to get them to see the beauty and power of it and to go the long route sometimes to make code that won't bite them in the ass a few months later. But now we're talking about developer aptitude and professionalism, a whole different matter. Frankly, we should be discussing architectural design and code reviews if that's the problem we're on.
People have been able to be quite productive writing apps in all kinds of all frameworks: Visual Basic, Swing, Delphi... not every framework has been well regarded, but many allowed inexperienced developers to write very interactive applications successfully.
On the web, we have a whole lot more people, and they are not inherently worse than the ones that gave us those old frameworks. And yet, we have a billion little frameworks now that don't age very well, and don't really make us more productive than in the old days.
Users not closing their tags? It's OK, we'll complicate the parser to accommodate them. Users want to interact with what should be static documents? No problem, we'll throw a scripting language in there. Users want to interact with hardware peripherals? OK, we'll just expose that.
The real tragedy is how much of systems research has died at the hands of this crappy sentiment of Good Enough that pervades the Web. Literally everything the Web touches gets infected with Good Enough.
I would reword it to "Good Enough For Now", because things do get fixed after the cool kids have kinda hacked around it for a while.
This is exactly the sort of defeatism and learned helplessness I was alluding to.
We've accepted this crappy universal platform because it distributes software well. Despite being in a discipline where we can easily change the tools to work better for us, we just sit here and take it.
Given that until very recently, the overwhelming majority of software consumers were also software producers, one can see how this attitude would be very attractive. It's New Jersey all the way down.
BTW I used to work on OSI based networking* - so I have seen solidly designed networking.
But some times "good enough for jazz" wins out over a more robust solution Beta vs VHS for example.
* Update apart from sprints X.400 offering that was rubbish
With links that work.
It's not any one bit, it's the fundamental design upon which it was all built. We're stuffing applications into a document viewer.
A very good document viewer that has through the path of least resistance had more and more tacked on until it evolved into the terrible application VM we know it as today.
Delphi, Swing, Visual Basic all had fixed static targets (in the case of Delphi and VB, the Win32 API which had excellent backwards compatibility) in the case of Swing the JVM which is legendary for that.
The web "ABI/API" is just broken by comparison, the primary language is a single threaded language that has much brain damage (controversial but I'll defend it) which isn't that surprising when it wasn't designed for what we are using it for (even nominally, insert joke about Win32 API as you please).
The other issue is that because the web is so damn big it has massive inertia making it very difficult to get people to move to newer technologies, in my dream world the web would have a proper (not asm.js) secure VM in the browser that could be directly used, the "webby" bit that renders HTML/JS would just be an application in that vm and other stuff could directly target the underlying VM, can't see it ever happening though as it requires the browser vendors to simultaneously agree on supporting an open standard without screwing each other over and then sticking to it.
That would be my dream web though.
Give me the very flawed, but still much more open web any day.
It's not all roses in any case.
Visual Basic and Delphi were tools with beginner friendly programming language. We had FrontPage and Dreamweaver to design earlier HTML4 frame & table based layouts. But there are no RAD tools to create modern CSS based web page designs.
* Client only vs. client-server:
Client-server web applications are a lot harder (software architecture), than Win32 client-only.
* Consistent API:
The WinAPI that was exposed through COM was easy to understand and more consistent than the HTML, JS, CSS that has grown over the years thanks to various vendor extensions/additions (Netscape, Microsoft, etc).
* Documentation, books, articles in magazines (copy&paste examples):
We used to have good API documentation and MSDN used to have a good relevant search (no C# API result if one search for C/C++ or VB API) and an index. Various magazines had really good articles with short example source code that one could type or copy&paste (web). Books shipped with a CD-Rom with a CHM file (earlier ebook format, Windows Help) that was similar to epub/mobi but the Windows Help viewer was far superior.
* Common controls:
Windows shell offers various common controls that are available in some form in VB, Delphi. The HTML standard still offers only very limited form controls. Were is the file list control, the menu bar control, etc?? Instead every website has come up with its own menu bar - thanks to DHTML movement.
* APIs vs. Frameworks:
In the Win32 world one used libraries (in form of DLLs) and its public API. In the web world one can do the same old fashion way by using C++ like languages like PHP with its hundreds libraries (exposes C API directly and optional object oriented boilerplate API) or the framework style (Ruby on Rails, etc., house of cards). If you know what you (and your team) is doing, you know what to choose in the long term anyway.
Nevertheless, I kind of prefer the HTML5 web app world over the vendor-lockin yet again that is Android vs. iOS apps. And real Win32 development is uncommon lately. But I would like a innovative RAD tool, a next-gen FrontPage/Dreamweaver - something that made Visual Basic so easy to use.
I don't do much web stuff now, but I'd still like to hear more about approaches to reuse in these frameworks.
I think the component thing is good though; it just needs to be something client side. Probably something like React.
React, and Om built on top of it, seem very interesting. They also seem to be built on abstractions that that get out of your way while guaranteeing good performance.
They may be working on dead platforms, without strong communities, breaking things as they fix or change other things, and doing it all so much slower than the original dev did. It will be interesting times.
It's bad enough to try to work on 5-year-old, well-known/popular paradigms in the brownfield, but try making what seems like a simple change to the brownfield while not being able to tear out the deadwood, and since-maligned, framework trends we've been building on now.
I chose PHP/Postgres/Apache/JQuery and Knockout.js
None of them are particularly exciting or sexy but I'll place bets on all of them still been around in 3 years and as a solo developer I chose conservative technologies I know really well (with the exception of Knockout.js but I needed something to marshal jQuery and Knockout fits my workflow really well (lots of forms and bits and pieces)).
Essentially I picked "boring" solutions, I like boring, boring is supported in a year, boring doesn't fall over at 2am for some obscure edge case, boring has taken it's beating and had it's rough edges warn off, boring has google results for "Unknown Error: FinangleFoo has thrown error 12131NOTDOCUMENTED".
I like boring.
I could (relatively) painlessly move to another framework (particularly Symfony2) the only major pain point would be the Eloquent ORM but as I've wrapped all that behind repositories the interface would remain consistent.
The many sites are going to be bit in a few years when the recent JS Explosion of new libraries wanes and we've got 1000 unsupported JS libraries out there and you're having to tell the department head the whole app UI has to be written, again, to keep up with that zag no one saw coming with the web.
For this reason I love Google Web Toolkit(I've done the ExtJs/Bootstrap/YUI/JQueryUI thing too) as it's totally open source, community driven, Google backed, and still going strong with releases and community support 8 years later. The beauty is with Maven, I just increment the framework version number and I get all those new compiler optimizations, IE versionX++ and Blink support for free.
As long as JS remains a shell of a language, I think compiling down to JS is the most sensible approach (i.e. Typescript/Dart/ASM.js/GWT) rather than having to fight the vagaries of torturing another trick from JS. Use a framework in a high level language that makes your life easier and future proof. Of course, one day ECMAScript might really become a serious language, but then I'll just update my GWT compiler and take advantage of that with a recompile.
Is this the same general idea? Or just another approach to rejecting the "MVC" paradigm as it was imagined on the web? Any other frameworks following this at all?
Having built out largescale backbone apps & android apps, I'm inclined to aggree.
Having built some what large backbone-apps, and then moving on to more mature frameworks, I personally think backbone apps just don't have the correct building blocks to scale.
For instance: data bound templates, computed properties, array/object proxies, controllers etc.
These things help tremendously with keeping the code maintanable.
This doesn't mean that it is inherently good at what it says it will accomplish for every project that it's used on. However, it does mean that on-boarding devs is considerably easier if you're using an architecture/framework that they'll likely be at least passably familiar with.
I'm all in favour of moving on, adapting and playing around with all of the hot new toys/frameworks but the broad "we" here at HN are in a bubble if we believe that the majority of our ilk has any interest in these types of discussions.
MVC isn't being used because it is the best at what it does, or that it is appropriate for all situations. It is being used because it is familiar to the vast majority of developers.
I've been struggling for a while to explain why I don't like MVC in web apps. Some of it is definitely just annoyance at how "MVC" has come to be simply a synonym for "good design" without any particular reference to any particular design, resulting in the term MVC being smeared over anything that has three classes that have a vaguely-plausible claim to fitting some interpretation of a "model" (this is the one most often got most correct), "view", or "controller" (both these latter just sort of get slung about with wild abandon). Despite how long it's been around, it is certainly a fad in every sense of the term, including large numbers of coattail riders and hangers on who don't really "get it".
But beyond that, regardless of what the "MVC" is, we've still got some sort of separation going on. But the separation is often pointless. The original MVC in the GUI arena was written for Ms, Vs, and Cs to be highly interconnected, not in the "coupling" sense but in the sense that there should be a significant number of many-to-many relationships between all the layers. But a lot of web "views" and "controllers" are used in only place, talking to only one other "thing", or perhaps the view talks to three "controllers" each of which is used nowhere else. The models are often reused, but more as just a data access layer.
If you don't have rich and free mixtures of all three pieces going on, you've split out your design on a useless dimension, and blown valuable design budget for a feature you're not going to use. And MVC is particularly designed for simultaneous usage of multiple things... one of the touchstones of needing the MVC model is when you have two simultaneous dynamic views on the same data, which multiple controllers may be simultaneously affecting. If you don't have that, seriously question your use of MVC.
Every once in a while, you may encounter a web app that really does deeply mix and match, in which case, go nuts. But it's going to be a special-purpose thing, not something used by everything. It's not always inappropriate... it's just that it's not anywhere near always appropriate, and it's appropriate rarely enough that it is, frankly, a stupid default for a web framework. Further, it's something that you can easily fold in only where needed; oh, do you have a statistics component where you really are using simultaneous views on the same underlying mutable data (perhaps a query)? Sure, use MVC for that. But as a default code structure? Be sure that mixing and matching Ms, Vs, and Cs at scale (not "I have this one class out of dozens that may sometimes need two views" but "this combination of 5 models, views, and controllers will be nearly arbitrarily mixed and matched") really is how your app's needs are going to change over time.
I cannot overstate the appeal of a prescribed architecture. This removes some of the essential anxiety a newer developer has when building things by narrowing the available choices. Rather than fret about where to put things, and how much objects should do, they have two neat categories to choose from. The problem is a novice/intermediate dev often knows they should be thinking about the design, but they don't know where to put things, so they waffle about things rather than just putting it somewhere and trusting themselves to fix it when they're wrong.
Combine a prescribed architecture with a relentless marketing campaign that repeatedly tells developers exactly what they want to hear: "blog in 15 minutes!", "design is wankery, just use the framework!", "testing just isn't worth it, it's too hard".
This is anti-intellectualism. It advocates ignoring software engineering principles established over the past few decades, and ignoring design feedback in the name of pragmatism.
Don't entrust your skills to a crappy framework. It will fade, much like the Web.
Don't entrust your skills to a crappy framework. It will fade, much like the Web.
The near-religious association devs have with frameworks seems to have almost displaced the association they had with languages. I'm not sure what prompts it, but frameworks die out even faster than languages. You don't have to work very long in the industry to see this happening.
Don't sweat that opinion, BTW. HN is not very kind to any sort of software engineering discussion. I presume this is a direct fallout of the Lean/"move fast and break things" ideology.
I'm sure someone will say, "but it takes too much time to rewrite it!" which in my experience is wrong. In fact you'll rebuild it faster because of what you learned in developing the prototype.
ORM systems almost universally suck, but so does the alternative.
I'd take a crap MVC design over the pre-MVC stuff I worked on any day of the week.
The thing you don't seem to be saying is what you're doing instead? You're just waving hands at the moment and saying it's bad, but it used to be much worse.
DRY. Just, DRY. If DRY leads you to MVC, rock on. But DRY is the real thing. It isn't a framework, and you have to think about it. But it's what you're really trying to do.
You're trying to define yourself the win by imputing to me a motivation to go "back" to crappy design. It's quite disingenuous, since I just got done complaining that MVC is often a crappy design, and logically concluding from that that I must want crappy designs is ludicrous once I call it out.
And if you further feel inclined to say "But you didn't give me an answer!", well, the need for "one" answer is part of the problem. There isn't one answer for which design structure will lead you to the DRYest design. Sometimes it'll be MVC. But you have to think. Not just knee-jerk MVC and think you've "designed".
People seem to think that if you dress software architecture up in the trappings of religious dogma, then it's easier to evangelize and recruit people to your cause. Well maybe they're right: it kind of worked for Larry Wall, for a while...
It usually turns out that there are more like 17 different essential concepts that you need to get a complex software project off the ground, but 17LAs like MVPATQSDYKRFXZFHW aren't as catchy, and are too hard to remember and pronounce, so they end up cramming everything that's not obviously M or V into the kitchen sink C.
DRY is great, but you should also DRTMOTP: Don't Repeat The Mistakes Of The Past!
Desktop app UIs were never this painful. Even Swing's.
Its tutorial (A walk on the seaside on http://seaside.st/documentation/tutorials) is rather basic, but shows the concepts well. (edit: longer article http://book.seaside.st)
Of course it has a different set of quirks to get used to, so it's not a cure-all - but it gives a different perspective on web-things.
I'd say anyone upset over MVC's leaky abstractions could better funnel that energy spent into making something better but I can't help to think that no software project is ever going to so neatly conform to having a structure imposed upon it.
That's the problem with prescribing an architecture ahead of time. That's why you learn the basics and improvise/draw on established architectures as the project evolves.
Django divides things into models, views and templates, which correspond to most other web frameworks' models, controllers and views.
One reason this division makes perfect sense is that the views and templates are worked on by different people. The templates are mostly HTML with some markup language and will be the responsibility of the designers. The views and models provide functionality and will be worked on by more backend-oriented programmers.
Another reason is that the views are actually reusable. You have generic views for browsing a model by date, or for a simple edit form. You can bind them to a model and skin them with a template to quickly get basic functionality that would otherwise require boilerplate.
That doesn't sound like struggling to me -- you've explained the fundamental problems with the MVC Cargo Cult perfectly! I'd love to read what you write when you don't feel like you're struggling. ;)
From: Don Hopkins
I'm interested in knowing more about the evolution of MVC and Morphic, and any other approaches that people have taken to user interface programming that you think are important.
I've heard about Morphic, but I haven't been able to find out too much about it on the web. My understanding is that it was originally written for Self, then ported to Smalltalk. Is it still in development, or has it morphed into something else? I don't know much about how it works or the ideas behind its design. What makes it unique and interesting?
There was a discussion on Reddit about "Is MVC the best pattern for web development", which is something I have strong opinions about and like to discuss!
I've drawn a lot of my opinions from this fascinating discussion on C2: http://c2.com/cgi/wiki?WhatsaControllerAnyway
Here's the reddit discussion, which is about how MVC applies to web development:
I posted a comment whose TLDR summary was "Fuck MVC!" -- It has a totally different meaning for web server programming, and in the 32 years since the term was coined, there have been better ideas.
There are two different meanings that MVC has these days: user interface MVC, and web server MVC. User interface MVC has its own problems, the least of which is being 32 years old. And nobody can agree on what a controller is, anyway, except that it's the dumping ground for all the brittle junk and dependencies that none of the other well defined classes wanted.
From: Alan Kay
Things seem to hang on in computing just because they work a little bit.
MVC was originally done at PARC almost 40 years ago. The good part was philosophical -- the idea to adapt the notion of "cameras" and "worlds" in the original 3D graphics stuff I participated in at Utah 45 years ago. The bad part of MVC was how we implemented it -- much too much machinery, etc.
We (my various groups since then, including Viewpoints Research) have not thought about MVC since, but have used and devised various viewing methods over the last 20+ years. I like to do views as "watchers" which do not affect what they are viewing. There are lots of ways to do this. Similarly, I like to also use "watchers" (context sensitive to the views) to catch needed inputs. We have never done a really satisfactory automatic inverter for dealing with the loss of "dimensions" that happen when a view is made (but we have done some experimental ones).
One important criterion is for end-users of all kinds to be able to easily make their own views in a very powerful ad hoc way via construction. We have done a number of adaptations and generalizations of how this can be done in Hypercard -- and this seems to work well (enough).
Since we always roll our own languages and development systems, we don't care about problems that other systems might have. For example, we have very little knowledge about C#, etc.
We do try to learn from the few good systems that are out there.
This sounds exactly like Doug Engelbart's "viewspec" idea in NLS.
It's always seemed to me that the "controller" was just extra baggage, because the view knew the most about drawing the model, and naturally would also know what it needed to reverse that projection back from user input through to manipulating the model. But right now we usually meticulously write the view drawing and mouse tracking code by hand, without a lot of help from the system. (That's something I consider a high art form, which I enjoy diong, so I'd probably be horrified and out of a job it it were too easy! ;)
I think Ben Shneiderman's term "direct manipulation" describes the style of user interface that Alan Kay was getting at -- or at least DM has to deal with a lot of the same problems: "continuous representation of objects of interest, and rapid, reversible, incremental actions and feedback" according to http://en.wikipedia.org/wiki/Direct_manipulation_interface ...
By that I mean DM user interface programming could benefit from some kind of automatic inverter, but usually it's just implemented in an ad-hoc manner, usually by input tracking code in the view.
I think the way Smalltalk and Self/Morphic use reflection to present editable user interfaces to objects is another example of a two-way mapping between projecting the view on the screen, and editing the model via user input. Booleans whose values you can toggle, numbers whose values you can drag up and down, color pickers and things like that are all fine and good, but for many properties it has to fall back to standard widgets that don't know much about the semantics of the data they're viewing or editing.
I had the opportunity to play around with Sk8 when I was at Kaleida. That certainly let you drill down, see and modify everything there was in the system, and it was totally prototype based! Plus it had cool looking windows with neat shapes, which I like! ;)
I'm curious about what Kay meant by "projection", and what successful examples there are of automatic bi-directional mapping, and powerful user composition. I take it that projection is the problem that you lose dimensions and have to hide information by flattening the structure out onto the screen (via a 3d projection or scaling or filtering or whatever infovis technique you're using), and there's no visible place to click or affordance to edit some every property of an object (or you have to build scaffolding in the form of clumsy indirect manipulation techniques like browsers, outliners and pop-up menus).
I started with this on some projects last year and find it simplifies a lot of things. To boot, you can now rather easily test your presentation logic with no UI dependence (it's all in the V).
With MVP all the persistence stuff is a whole different place, in the REST/RPC services on the server (services and repositories) but it has no coupling at all with the UI or MVP. Makes life a lot easier.
So, consider a textbox on screen and an integer attribute on a model.
A bijective function might be a pair of (intToString, stringToInt) functions; one is the getter that projects out of the model, the other is the setter that takes from the view and pokes into the model.
Next, start think about how to compose bijective functions. How might they be packaged into bundles that represent a sub-component view of an individual model amongst many. And what might the mapping from a collection model look like; consider detail views (as in master-details), with a source of "currency" you can map from collection to "current item", and so on.
Here is an article I wrote about constraints in OpenLaszlo and Garnet:
Constraints and Prototypes in Garnet and Laszlo
Oliver Steele (one of the architects of OpenLaszlo, and a great Lisp programmer) describes how OpenLaszlo supports "instance first development" and "rethinking MVC":
I've used OpenLaszlo a lot, and I will testify that the "instance first" technique that Oliver describes is great fun, works very well, and it's perfect for the kind of exploratory / productizing programming I like to do. (Like tacking against the wind, first exploring by creating instances, then refactoring into reusable building block classes, then exploring further with those...)
OpenLaszlo's declarative syntax, prototype based object system, xml data binding and constraints support that directly and make it easy.
OpenLaszlo's declarative syntax and compiler directly support instance first development (with a prototype based object system) and constraints (built on top of events and delegates -- the compiler parses the constraint expressions and automatically wires up dependences), in a way that is hard to express elegantly in less dynamic, reflective languages. (Of course it was straightforward for Garnet to do with Common Lisp macros!)
My approach to it has been to avoid implementing design patterns as classes as much as possible - after all, doing so misses the whole point of design patterns.
I'm spending a lot of my time now writing about the MVC pattern as a conceptual entity and documenting coding techniques, with the goal of putting the architecturing and engineering responsibilities back in developers' hands (as opposed to doing it for them inside the framework... and failing like everybody else)
It's a bit disheartening that there's so many people jumping into the latest AngularJS education bandwagon, but almost no one bothers to try teaching the age-old underlying concepts that are actually valuable and that people can use for the rest of their careers. I'm hoping to help correct that with my work on Mithril and the blog.
What's tough is if you are just building something that's free / ad supported, where the revenue per user is minimal, so making every last bit of resources counts.
But yeah. This expresses a lot of the things I feel about MVC for the web.
This is obviously trolling.
But taking a few steps back from which three letter acronyms to use:
User interface software architecture is so dogmatic and cargo cultic these days, compared to how wide open and free wheeling it was years ago when nobody agreed on anything, and people were experimenting with building all kinds of uniquely original systems from the ground up, instead of iterating on imitating imitations of imitations like they are today.
One book that deeply impressed and influenced me, and made me realize how many extremely different approaches and ways of thinking about user interfaces there were, was "Methodology of Window Management", the proceedings of a 1985 workshop where an amazing group of brilliant pioneers got together and discussed a wide range of vastly different approaches and ways of thinking about user interface architecture and software design. Fortunately it's online now and you can read it for free!
F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams.
29 April 1985.
This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme.
The Proceedings were later published by Springer-Verlag in 1986.
It's got some great historical retrospectives, like Warren Teitelman's "Ten Years of Window Systems - A Retrospective View", describing much of the groundbreaking work at Xerox PARC: http://www.chilton-computing.org.uk/inf/literature/books/wm/... -- and some papers about cutting edge technology of the time, like James Gosling's "SunDew - A Distributed and Extensible Window System", which was the original name of NeWS: http://www.chilton-computing.org.uk/inf/literature/books/wm/... .
For example, AJAX was not invented in 2005 -- that's just a recent buzzword for a much older good idea:
"There was a general view that the ability to download procedures to the window manager was a good way to tailor facilities to applications, for example to filter out all mouse events for a particular application. The same effects can be obtained through table-driven systems, though downloading was felt to be more elegant. However, there is still more work to be done in this area."
Even though some of the information may seem dated and laughable, like the "Interface to GKS": http://www.chilton-computing.org.uk/inf/literature/books/wm/... -- it's still valuable and amusing reading, just to get the perspective that people haven't always agreed on basic concepts like what an icon is, or what you can do with a window, and that there is still a lot of room to innovate if only we stop rehashing old ideas. The back-and-forth in the working group discussions is fascinating and prescient, and I think it's even more interesting to read today than it was before, to compare their predictions and recommendations with what's evolved over the 29 years since it was published.
Icons are regular (small) pictograms which may be defined and changed by applications. They can serve many functions, frequently to conserve screen real estate. They can be used as an alternative to a window as in Cedar; as an alternative representation (perhaps concurrently visible) of the window (Sapphire); or as a representation of a task to be invoked or data which is to be operated on (STAR, Macintosh). The icon can thus range from an application-prescribed static bitmap representation to an entity which has all the attributes of a window (eg can receive all types of input). Since use of icons in user interfaces is commonplace. the provision of support in the window manager for operations on them is desirable."