The book Built to Last has a famous discussion of the "Tyranny of the OR," pointing out that mediocre companies force themselves to choose short vs. long term, or values vs. profit, or whatever; while great companies find a way to do both things at the same time. The desired state isn't balance (some values, some profit); but both. Do both things 100% by coming up with innovative and clever approaches, don't trade off one vs. the other.
A cliche computer industry example, perhaps, would be all the search engines that lazily traded off user experience vs. advertising revenue; while Google spent the time to figure out how to have better user experience, and more advertising revenue, at the same time. I like to think the RHEL/Fedora model Red Hat arrived at after many years of trial-and-error is a similar kind of thing; other companies either settled for a "proprietary frosting" model or failed to become profitable. I won't try to take a position on whether Google or Red Hat will (or do) manage to consistently get it right, but these two examples make sense to me. Another open source company that seems good at this is Trolltech.
I don't really want to talk about the computer industry, though. My favorite examples (what I really want to blog about) are a couple of magazines I read, Game Informer and Entertainment Weekly. Most magazines about video games or entertainment are terrible, full of fluff crap, gossip, more ads than content, and unreliable reviews.
These two magazines both have a similar format, which I think of as the front half and the back half. Before a movie/book/game comes out, they will do almost-always-positive "preview" articles talking about why the thing could be good, interviewing the people making it, and discussing the concept. These articles are fairly advertiser-friendly, but I think are also what readers want (or at least what I want). I want to hear why the director or game designer thinks their product will be exciting, so I can judge for myself. I wouldn't want some snarky magazine writer's opinion at this stage. Everything gets a fair chance at success. The cover story and cover art normally point to articles in this "front half."
Both magazines then have a "back half" consisting of reliable, well-written reviews that are perfectly willing to be negative. These appear "just in time" when the movie, book, or game comes out. Often the same product appears in the "front half" first and then "back half" in the following issue. The magazines both seem to avoid putting a preview and a review of the same product in the same issue if they can help it.
The magazines even have a similar tone, with a lot of humor and a level of intelligence somewhat above e.g. the Boston Globe or Associated Press movie/book reviews, but less pretentious than the New York Times or Time Magazine reviews. And they have readable graphic design, vs. the our-Quark-XPress-person-is-on-acid train wrecks you can find on the newsstand. Finally, they tend to cover all products, not only blockbusters or only independent/artsy stuff.
The upshot is that these magazines appeal to a wide audience, they are advertiser-friendly AND reliable advisers, both fun to read AND smart. To me that makes them great role models.
Occasionally I check in on Internet Explorer, and I always notice that when you open a new window it displays the same page in the new window that you had open in the previous window. I'm pretty sure this is the only page on the Internet that I could not possibly want to see in the new window, since I already had it open. A search box or blank page would be a much better guess. Epiphany and Firefox both get it right.
I haven't thought about a canvas widget too often in the last couple years, but when I did it was along the lines of "well, most apps stopped using GnomeCanvas, so I'm not sure an official GTK+ canvas is important." This weekend I looked into it a bit and wrote up some notes. Now I think a canvas could be huge, if done properly with a focus on the right kinds of high-level features.
Jeff, what isn't clear to me I guess is what structure or process do you want? As I see it, it isn't very complicated; there are designers, and you work with them collaboratively to figure out how to approach a problem and implement it. A variety of apps and features have been approached this way, such as Epiphany, Evince, file selector, NetworkManager, Sabayon, some of the Google Summer of Code stuff, Yarrr, etc. The good design examples that got implemented have involved solid one-on-one communication between the designers and coders. So the process is just that, find a competent designer and work with them. Perhaps we should state this officially somewhere and kind of map out how a typical collaboration would go, with some examples.
There are examples of developers who have done good designs on their own, too; some people are OK at this and some are not. The real problem is people who are not but don't realize it, of course. ;-) At least 90% of us really are not OK at it in my view, unsurprising since it's a full-time career and so is programming.
I don't believe that design can be done by committee or on a mailing list. 2-3 designers in person with a whiteboard can maybe work, but 20 people on a list is just a train wreck. Especially when 15 of the 20 don't have a clue in the world (25% with a clue is optimistic, too).
Maybe we also need to spell out the distinction between design and usability. The rough process I would say:
Design -> Code and Design Iterations -> Usability Testing and Polish
(coder comes to design team
as issues become apparent;
everyone learns from users
with release-early-and-often)
The purpose of design is the "what is it?" question. Netapplet vs. NetworkManager. Sabayon vs. KDE Kiosk Tool. Those examples are on a whole-app level, but the same "what is it?" question also comes up with each smaller aspect of an app. See the lightbulb joke.
Bryan and Seth at least tend to focus on projects where they can have a large impact, vs. say running around CVS pointing out that gnome-system-monitor thinks that Mebibyte is a reasonable choice of words. In their place I have to say I'd do the same, as bugzilla is full of "how to word this dialog" questions and it's just higher-impact to focus on the "what does the desktop do?" questions. I agree with Seth's argument on that point.
Also, obviously, the design guys tend to work with really helpful developers such as Marco or Dan before they work with some of the shall-remain-unnamed not-so-helpful developers. Seems pretty sensible, nobody likes banging their head on immovable objects.
Jeff, Bryan and Seth were both at least a "design team" prior to working at Red Hat and have continued to work in the same way while working at Red Hat, so my view is you should leave corporate names out of it and just talk about people if you want to talk about people. I don't know if they are the "official" design team or not, but they are definitely (with Calum) the authors of the HIG and AFAIK the only people involved in GNOME who can claim to have substantial interaction design training and experience.
But really it's immaterial what is on their diploma and resume. The fact is that they are good at this, just as the rest of us are good at the work that we do. And Bryan's design for notification is a good one and he posted it openly at some considerable expenditure of his time. This was not posted at Red Hat's request. Neither was Colin's post or John's. These guys have been trying to engage in an open discussion on how notifications should be done, which I don't quite parse as an example of "closed development."
To me this is an example of open discussion and (while I haven't asked) my guess is that Bryan posted his notification design even though he assumed it would be a waste of time since he'd have to get in silly flamefests about it and people would just implement some random, bottom-up thing anyhow. I'd guess that Seth would not have spent time on a design for that reason, and GNOME is mostly proving his point at the moment so he'll probably taunt Bryan on Monday and they will both return to working on projects where the developers listen to them.
If people don't appreciate the value of design skills and take advantage of them then GNOME (and Linux) are hosed. I find well-designed Evince for example just unquestionably, definitively superior to other similar efforts on Linux. Some people will disagree but then, dozens of people disagree with the coding decisions I make, and I'm taking feedback but I'm not taking a poll. That's because I want a successful project, not an everyone-gets-a-vote project.
There's the criticism one could make that design is telling other people how to do the work without doing the work. Two points here. First, this claim implies that design and usability don't count as work, which is bullshit; if done competently they require quite a bit of work. Second, nobody is stopping anyone from doing the work the way they want. Go for it. Open source lets you. However, for many developers their no-design-input work is going to suck and I for one won't have qualms about pointing that out.
My personal view is that it should not be the job of GNOME's designers (whoever they are) to go around finding and arguing away every wrong direction. Instead, programmers should be actively seeking the right design before they type in a load of irrelevant code and specs.
On to your general point about closed company discussions. I half agree and half don't. NetworkManager as far as I can remember has been in GNOME CVS virtually from day 1. I don't know when Dan moved it from his hard drive to CVS, but I know from the logs it was in CVS before it worked at all, over a year ago.
You refer to the "netapplet/NetworkManager debacle," which I guess means debate over which to use or which was right. I posted to GNOME lists numerous times arguing for the NetworkManager approach (specifically in the context of gnome-system-tools, IIRC). This was debated quite a bit. And when we started doing it the IMO right way, it was in CVS the whole time. netapplet and NetworkManager are entirely different and there was no meaningful code that could have been shared between them. That's why you have to design first and write code second, because design is about what to write not how to write it.
I didn't really see a lot of debacle here to be honest. It seems like NetworkManager is agreed to be the right approach and everyone is working on it and I never saw any huge flamewar or anything. Maybe someone is quietly pissed off and I just don't know about it, I don't know.
So I don't know what the problem is, in some ways. Similarly for e.g. Sabayon - it's in CVS and always has been. Gamin - it's in CVS and always has been. Yarrr - ditto. X.org/Cairo/Luminocity - ditto. We make web sites and mailing lists for this stuff and use them. What is the big secret non-public project you think we are working on?
I said I half agree and half don't. The half I agree with is that yes you aren't seeing a high level of engagement from Red Hat and Novell on the core GNOME pieces. I think there are a few explanations. First, we are largely working on surrounding pieces that need more work. For example HAL and X.org rather than gnome-panel. Second, people sharing a hallway naturally have hallway conversations. However, with 1/3 of our desktop team remote this is a problem for us as well as GNOME, and we do not have an internal technical list. (We do have internal IRC, and some people like me have dropped off external IRC due to lack of time. Though, I have always gone through IRC-absent periods in the 7 years I've done GNOME stuff.) Third, the language split is leading to multiple projects in the same category. Fourth, the companies are just working on different things because they have pretty different ideas on what the priorities are, so they aren't having to talk to each other too much. I'm not just saying Red Hat and Novell here; also Canonical and IBM and others.
On the projects that do overlap, it seems to me the communication and openness is pretty good, e.g. on HAL, X.org, and so forth. Or even notification systems since there is currently a lively discussion and I'm pretty sure I've seen it discussed in the past too.
Led by the fearless jrb and the Gazpacho team, a bunch of us sat down to hack on Gazpacho today.
My only useful accomplishment was a hack to allow toplevel windows to be displayed on a "work table," like so, rather than the old Glade-style standalone windows. It shows how mature pygtk is that you can do scary not-really-allowed gtk hacks with it.
Then we spent some time talking about how to rework the layout of the app, yarrr whiteboard with a proposal (double-click the whiteboard thumbnail so it's large enough to see).
The delta from current Gazpacho would be:
There's a similar single-window proposal already, the differences we came up with were to put the property sheet on the bottom and palette on the right, drop the Selector button, and use a single "work table" in place of an MDI tab per-widget. Also dropping the toolbar and doing the reduced "most useful items" property sheet while hiding the full property sheet.
With our proposal the default Gazpacho screen would be mostly occupied by the work area, the only visible items with widget tree collapsed would be palette, 5-10 property sheet items, and menubar.
Some other Gazpacho suggestions to read here.
I think an essential element of "nice feel" would be good design to the "work area"/"work table" widget. It needs to be easy to drag a child widget out onto the work table to temporarily remove it from a layout, then drag it back to your layout later. Each widget should probably be tagged with its Glade name and this name could be in-place editable. Toplevel widgets would ideally use libmetacity-private to show what their window decorations would be like (and allow resizing). This also makes it easy to distinguish toplevels from other widgets on the table.
In-place editing for widgets would really be nicer than property sheets in a lot of cases, but it's so hard to implement that it's probably not worth it.
A while back I posted some thoughts about version control, I feel like these posts get at the same point.
People are artificially restricting the design by accepting the same "boundaries" as CVS, leaving bugzilla, email, an IDE, mailing lists, etc. all out of scope and with a fixed relationship to the version control system.
Recent funny-because-its-true bad joke from Red Hat exec David Burney:
Q: How many designers does it take to replace a light bulb? A: Does it have to be a light bulb?
"Does it have to be a light bulb?" is the right question here. The design space is best taken as something like "a system for maintaining an open source project," not "a version control system."
If someone submits a patch, I should be able to just click "apply to HEAD" and it's done. It shouldn't be about getting a clean checkout, downloading patch from bugzilla to local drive, applying patch (figuring out which patch options the person used), creating the commit message, etc. Should be just one click.
Looking at all the open source version control systems out there, I don't really see why they improve my life significantly over CVS. But if one of them addressed the overall workflow like this I would absolutely be interested.
