Symphonious

I've been doing a lot of thinking lately about how to make wikis accessible to the common man - in other words, how do we get wikis to spread out of the technical departments and make it not just usable by non-technical people but make them actually want to use it and advocate it. Certainly there's been a lot of movement in this area and a lot of good progress made, but I suspect there's a lot more than can be done.

Certainly at Ephox, we seen the operations, sales and marketing people make heavy use of our internal wiki - I tend to attribute that to a couple of reasons:

1. We configured the wiki to use HTML. While the technical people don't tend to leverage this that much, the sales, marketing and operations people regularly build well laid out pages with tables and columns etc. There's summary boxes for quick overviews and graphics to highlight points etc. Some of it could be done with wiki markup but most couldn't. Many people think this increased flexibility in presentation distracts people from the content, in fact it's quite the opposite. It provides ways to highlight information, to design the page so it's most useful for readers and to make navigation much easier.
2. We have a great WYSIWYG editor so people didn't have to learn any kind of markup. You can still switch to code view to tweak things by hand if you want, and people do, but by default you can just get to writing your content and laying it out how you want without having to think about the rules of HTML or wiki markup.

I think it's the combination of the two of those things that made a real difference to us. HTML by itself would be too hard to edit. A WYSIWYG editor for wiki markup distracts from the content without providing the flexibility to really lay out the content in a way that helps the reader. A lot of wikis these days seem to be falling into this second trap - their users complained about having to learn wiki markup so they added an editor. Unfortunately, the editor really doesn't do a lot more than let you type plain paragraphs and headings and insert images more easily. The lack of powerful table support (including nested tables) hugely reduces the ability for users to structure a page the way they want. Using tables for layout may not be exactly up to speed with modern CSS techniques but it's something that people understand and have been doing in Word for ages so it works.

The trouble is, that's just one use case in a company that is kind of technical anyway. I know of at least one company that failed to get adoption because of wiki markup but that's still not a great sample size. I'm really keen to hear other people's experiences with what made a difference to wiki adoption in all kinds of companies or particularly what caused the wiki to fail. If you've got some experience with getting non-technical users to adopt wikis I'd love to hear from you either in the comments below or my email and phone number are just over there on the right.

One of the things I've often found annoying about Brisbane, and to a degree Australia in general, is you just don't get enough chance meet ups with interesting geeks. So since I'm over in San Francisco at the moment and Robert Scoble invited everyone and anyone to join Tom Conrad and him on the top floor of the Marriot hotel to watch the fireworks, I figured it was worth the walk.

Turns out that only a few people thought of that particular vantage point so when I got there Tom and Robert had secured the best seats in the house. Conversation was great, both Tom and Robert are very down to earth and easy to get on with. We were saved from getting too geeky by Robert inviting over a couple of girls who hadn't secured good seats but it was good to see some of the stuff put in perspective and get a non-geeks view on things as well.

The only problem is that I still haven't found an American beer that's worth drinking…

(click for the full sized image)

Hopefully Robert will upload the video he took of the fireworks somewhere. There were some amazing effects - hearts, smiley faces, cubes. I had no idea they'd discovered how to do that with fireworks. Very cool.

I mentioned that I was chatting to a reporter after the Java Libre panel yesterday. The article she wrote is now online and it's a pretty good summary of the key points of interest in the discussion (it skips all the bits where everyone agreed in true reporter style though). I think she did a pretty good job of understanding what I was attempting to say (I elaborated more on that yesterday). We even got an actual link to ephox.com which is unusual.

There was an interesting panel discussion at JavaOne today about the open sourcing of Java. The panel was made up of folks developing open source JVMs and a representative from Sun. Compatibility is obviously a common theme to these discussions and there were a number of mentions to just how bug for bug compatible the alternative JVMs are trying to be. It occurs to me though that if all the implementations wind up behaving in precisely the same way, there's not really any point to having multiple implementations. Yes multiple licenses are nice for particular niches but for the average Java developer, what's the benefit?

A reporter came up to me after the session (apparently I'd made some good comments) and asked about what benefits I saw. Her first question was about how useful having the source code would be. The trouble is, the source code for the standard Java class library has been available for as long as I can remember and open sourcing Java doesn't change the legality of copying and pasting code (unless your product is GPL) so there's no real advantage in source access. There are a few sun.* classes that now have source code available and didn't previously which can be useful but not overly so.

The other advantage is that was mentioned by the panel is that you can fix bugs for clients *now* instead of having to wait for the next release of Java. Of course, for the average developer this isn't really an option either because it would involve deploying the fixed JVM to all their customers. It might be feasible for people running controlled servers that just run their apps but it's unlikely to be practical very often. You could however add a workaround to your application for now and contribute a fix back to the JDK for the future which is likely to happen a fair bit.

One interesting aspect of contributing fixes back is that in a lot of ways, there is an incentive for companies not to contribute the fix back - they now have one less bug than their competitors. If the fix requires significant maintenance contributing it back is a pretty clear win, but many work arounds don't have any real need for maintenance. They might be in areas of code that are very infrequently changed, they might be modular enough to be quite separate etc.  Ephox products have a lot of work around for bugs in various browsers, JREs and OSs, many of which receive so little attention and maintenance that we can be surprised to find them years later, still working perfectly and still working around an unfixed bug (we do report these to Sun, but few people run into them so they tend to be low priority). The other consideration is that even if future versions of the JRE include the fix, you still can't remove the work around because the older JVMs are still in use by various clients, so you pay the maintenance price anyway.

There are other business considerations involved with the decision to contribute to the JDK as well - you have to sign the copyright on the code over to Sun which can be a sticking point with a lot of companies. After all, why should Sun get to sell the code that you paid to have developed? (And Sun does still sell the code, they have a bunch of different licenses for the Java code including commercial ones, not just the GPL). You also have to go to the expense of reviewing the various legal agreements for contributors and going through the patch review process etc. It's not just a simple matter of putting the patch on your blog and it being magically part of the JDK.

It will be really important for the OpenJDK team to work hard to limit these barriers to contribution if they want to attract contributions. I'm certain it's something that they're already thinking about, but how it pans out with the lawyers will be interesting to see.

The other potential benefit that an open source JVM may provide is the ability to port it to other OSs and architectures. People are already suggesting that this will mean OS X will always have up to date Java just by recompiling. Unfortunately, it's just not that simple, you first have to port the JITC to output PPC code instead of x86 which is a huge job, then you have to rewrite the AWT toolkit implementation to work with Quartz. Then you have to write a plugin that works with OS X browsers and deal with all the Cocoa vs Java threading issues. Then you have a working JVM, but still no native L&F, no tie ins to the OS (Apple provide some reasonably simple but very powerful features like being able to put the menubar at the top of the screen and handle dropping files onto the application etc). It's good that it's possible to port, but it won't happen soon and it won't be easy. Judging by the number of Apple laptops here at JavaOne there may just be enough interest to get it done though. BSD is also a likely candidate for a porting project and that should be a lot simpler.

Beyond that, Java developers aren't going to see much difference except possibly that they have to stop making assumptions that if it works with Sun's JRE it will work anywhere. Of course, that's never been true anyway, particularly from a performance perspective, as people who have brought apps over to OS X have found out. It's a huge change for the Java community, but one that only a very, very small subset of the community is going to be affected by.

The session was a lot more fluff than useful stuff and often went for showy graphics instead of actual usability which is a shame. There were some good ideas though.

• Use a modern L&F - they suggested Nimbus. Gosh it's ugly and gray. I suggest using the system native L&F (except on Linux and Solaris then anything is an improvement)
• Add a splash screen, can do this with the -splash argument in Java 6.
  • Supports alpha transparency so can be non-rectangular
  • Should provide a progress bar.
    • They used a sepia image fading into color to show progress which looked cool but didn't really show progress at all effectively.
• Validating Data
  • Give feedback immediately.
  • JGoodies can provide a small icon in the corner of the component. You can do this yourself by painting the icon in the layered pane's popup layer.
• Custom Components
  • You can improve GUIs by creating custom components.
  • This is where they messed up usability in some places. Make sure your custom components are significantly easier to use than the standard components otherwise it's better to go with what the user is used to. Also need to consider accessibility which they didn't mention at all.
• Improve interactivity by updating search results immediately as the user changes values.
• Use cyclic gradients for improved performance, even if you don't need the cyclic property (just paint one iteration).
• Measure text with:
  • g2.getFotnMetrics() then stringWidth and getAscent
• JList has a setLayoutOrientation method which lets you use it as a multicolumn list.
• You can span text across all the cells in a row by clipping the text with a JViewPort to show just the section inside the cell currently being painted.
• You can animate the changes made when sorting by painting the animation in the glass pane over where the table is.