The effort has been two-fold. Actually laying out slides is probably a pretty obvious first target. I’ve been using draw2d from GEF for this and have had some success. One of the things that drives me nuts about existing presentation software is the whole WYSIWYG editing paradigm. Frankly, I hate pushing pixels around to make stuff look right and to simply fit on a slide. Open Office is particularly annoying in this regard; in some of my presentations, the title is in a different place on almost every slide and, frankly, I can’t be bothered to spend the time to tweak each slide to make it right. Most of my effort in this area has been to automate the assembly process as possible.

Some of my effort has been around just making stuff automatically fit. I just specify a bunch of bullets, and slide render makes it fit by reducing the font size until everything fits. Its a simple algorithm, but it works. Want to add a picture? No problem, a few simple rules govern the placement and the text just flows around it. Graphics inside text is also easy using draw2d (the text management stuff is quite awesome).

The missing piece as always been the mechanism for editing slide content. A while back it occurred to me that content can just be specified using wiki markup. For example:

=Slide One Title=
* Bullet one
* Bullet two

=Slide Two Title=
[[Image:fascinating.png|right]]
* Bullet three
** Nested bullet one
** Nested bullet two
* Bullet four

The basic idea is that the heading, denoted by the equals sign (=), the slide title. Everything between this heading and the next is the content of the slide. The second slide shows a picture that will be rendered to the right of the bullets. I envision adding support for some other tags. For example, [[Method:/MyProject/src/org.eclipse.stuff.MyClass#myMethod()]] will render the contents of the specified method on the slide (taken live out of the workspace). I’m not quite there yet, but I think it’d be cool.

Using the wiki-style text will make it easier to collaborate, track changes, change templates, borrow slides from other presentations (imagine an “include slides” markup), and more. My presentations will just be projects in my workspace (images are found relative to the markup file). Most of my images are screen shots anyway, so they’ll be easy to include. More interesting images can be created with GIMP, or possibly with an SVG editor (I’ve read that GEF provides some SVG import support that I need to look into).

I’ve decided on using the MediaWiki markup for this as it’s what we use on Eclipsepedia, so I’m already familiar with it.

The best part is that most of the work has already been done. The WikiText SOC project (completed under the supervision of the Mylyn project) has implemented a Wiki parser that I’ve managed to leverage. I haven’t looked at the editors yet, but I imagine they’ll be helpful as well.

My intent is to clean up the code and contribute it to the Examples project. The initial version will provide basic image and text support. At some point in the future, I’ll sort out the method displaying option, and look into things like table support. I’ll post some pictures in the coming week.

In the meantime… is this a crazy idea?

A community does stuff for you. As you develop a community of users, you’ll get feedback. Feedback is valuable to every project as it lets you know if you’re doing the right sorts of things. When you’re successful in developing a community, you’ll find that they do even more for you, including great contributions of ideas, code, tests, testing, and far more. A well-developed community is a great source for new blood into your project: new committers come from your community. If you’re fantastically successful, a community will do great things like answer questions about your project and technology for you on IRC, newsgroups, mailing lists, and other forums. They’ll write books, fill out documentation, do presentations, tell others, and more. In short, if you’re successful in developing a thriving community, your work gets easier.

You’ll know that you’ve been fantastically successful with community development when you stop being the center of the universe for your project. Unfortunately, many of us have hard time letting go of control.

Developing that community is hard work in the beginning. You actually have to get out there, find your community, and engage them. You have to deal with disappointment: some of your efforts to find your community will fail. You need to push through the disappointments and look for new opportunities.

One of the best things you can do is make easy for your community to find you. Make sure that your project’s web site is up-to-date. Make sure that you have a concise description of why it is that your project exists (make sure that the description is on your project-info page and that the project-info displays correctly). Provide links to your newsgroup. Actively monitor your newsgroup and answer the questions. Lurk on eclipse.newcomer and IRC (#eclipse on freenode.net). Be there for your community. When people try to engage you, engage them back. Turn those early adopters into ambassadors and evangelists for your project. Be aware of the landscape. Make connections with other projects. Avoid becoming one of those “not invented here” projects. Use other project’s stuff when you can. Leverage their communities by lurking in their newsgroups.

Help people get involved. Make sure your project plan is up-to-date. Make it as easy as possible for interested parties to get your code; provide Team Project Sets or Buckminster specs to make getting the code out of CVS/SVN simple. Provide a link to find existing bugs and a convenience link for creating new ones. Make sure your download page is easy to find.

Get out there. Developing a community requires effort, but the payback makes it worthwhile.

Gunnar has also been appointed to the Eclipse Architecture Council as the Technology PMC’s representative.

I look forward to working more directly with Gunnar.

Gunnar: congratulations, and welcome.

Actually, I learned a couple of things before I learned the interesting part. First, Javaco currently works on Windows. Try as I might, Linux just isn’t supported. Lesson learned: read the documentation before spending an hour hunting down a bug that isn’t there.

Javaco goes through your user interface and determines whether or not it is valid to call it “accessible”. It looks for all kinds of things, like whether or not tooltips have been provided for fields and buttons; it also does this clever label/text association that I haven’t quite gotten my head around (a text field has to have a corresponding label).

Using Javaco is pretty easy. I selected a class that extends SWT’s Composite class, and selected “Accessibility Tools > Perform Validation” from the context menu. The result looks something like this:

My first error threw me for a loop: it told me that my composite was “Missing Accessible Name”. “No problem”, I thought, “I’ll just have to set that.” After a few minutes of fruitless searching, I determined that there was no method that reads anything like setAccessibleName anywhere in the SWT Text widget’s hierarchy. I was stumped. After regrouping, I came across the getAccessible() method. With a little help from the javadoc, and the SWT snippets page, I was back in business.

The Accessible Name for a widget is text that can be spoken by an accessible computer to help a user navigate through a form. You don’t actually set any value; you have to tell the widget how to respond to a request for it. Code along these lines does the job:

this.getAccessible().addAccessibleListener(new AccessibleAdapter() {
	public void getName(AccessibleEvent e) {
		e.result = "Enter personal information on this form.";
	}
});

You can (and in some cases are required to) set other values, including keyboard navigation equivalents on push buttons using the listener.

Javaco found a bunch of other problems, such as some missing tooltips (which I believe the accessibility software uses for the accessible name when available). I’m still pretty new at this, so I’m sure that there’s much more that it can (and will) expose as I play with it some more.

Javaco adds several new views to the workbench, including the “Rendered GUI” view (shown bottom left above) that manifests the composite you’re testing. The view is live and you can interact with it. It’s pretty cool: whenever you save the code, the Rendered GUI view gets updated. This is pretty handy all by itself (you can test your composite as you’re building it without have to explicitly test). The “Validation Report” view (shown bottom right above) summarizes the results of validation. The “Rulebase Viewer” view provides an overview of the rules that the validator uses and seems to have the ability to extend the set of rules.

If you’re building applications that need to be accessible, then you need to spend a little time with ACTF.

So far, most of the work has been on just getting things started. First, Dwight created the “JavaLite” environment which includes a new perspective, new view, and a couple of wizards that streamline the development process a bit. I’ve been spending a lot of time (too much, really) getting those pieces that we do have to build into a coherent update site and a downloadable package. In the process, I’ve come up with a few ideas about a common build infrastructure, but that’s a story for later…

I’ve been testing the Windows and Linux versions. Unfortunately, I don’t have access to a Mac, so I can only hope that I didn’t screw that package up. Here’s a screen shot.

I think that we’ve managed a reasonable first cut, but there’s a lot more to do. For starters, I don’t like the name “JavaLite” (sorry Dwight); I prefer something more along the lines of “Assignment Explorer” (but I’m still not happy with that). Your comments are welcome on bug 244644. I’m also convinced that we can do more than just strip down the existing wizards; I think there’s a better paradigm and am looking forward to experimenting with this a bit. In the meantime, I’ve opened a bunch of other feature requests and bugs if you’re looking for something to do…

Dwight’s going to unleash this on his unsuspecting first-year students this term (he’s a professor at Carleton University). We’re going to carefully monitor their use of the environment and drive their feedback into evolving the IDE.

More information about the component, including download instructions are available on the component’s wiki page.

As a few of you are already aware, I’ve started a process of going through the many projects that fall under the Technology Top-level project. I’m reviewing these projects for a couple of reasons: first, I need to know more about what they do, why they exist, and where they are going. I want to be able to effectively tell people about these projects. Second, I want to make sure that these projects are doing the right sorts of things to set themselves up for success.

I’ve decided to go through them alphabetically, so ACTF and Albireo have been the first to suffer my wrath benefit from some gentle prodding (Voice Tools Project, feel free to start without me). I’ve been looking the projects over with an eye for liveliness. Active participation by project committers is certainly a part of that, but I’m more interested in the community being developed around the project. At Eclipse, the community is king.

I’m looking for a few things:

Is the project’s information complete and up-to-date? Does the project’s web page contain enough information that readers have a fighting chance of understanding what the project is all about and what it provides? Is the content grammatically and technically correct? Is the project-info page complete? Is there a project plan? Is it easy to find? An important part of developing a community is making the barrier for entry as low as possible; making your web presence as complete and correct as possible goes a long way in this regard.

How big/active is the community? This is difficult to quantify, but you can get a general feeling by looking at the activity on the newsgroups and mailing lists. Are the project’s committers engaging with their community on their newsgroup(s) (i.e. are they answering questions in a timely manner)? I look at the Bugzilla records: are folks other than the project committers raising bugs? I also look at download statistics.

FWIW, all projects should have at least one member monitor eclipse.newcomer.

How does the project define their community? Developing a community is easier if you know who your target audience is.

How is the project engaging the community? Does the project have at least one member blogging regularly? Is that blog aggregated on Planet Eclipse? Is it aggregated elsewhere? What conferences are project committers speaking at? What other forums are being used?

I’m approaching this in a how-can-I-help-you-help-yourself manner. The fact of the matter is that I don’t have any real sticks that I can use in this role. Despite what some of you may have heard to the contrary, I don’t generally like using sticks anyway (I’m more into the empty-hand thing). I hope that you all agree, that developing that all-important community is important and that we can work together to make it happen.

A reviewer needs to be an expert in the subject area of the article. Ideally, reviewers are Eclipse committers (but I don’t think that this is an absolute necessity). The reviewer’s job is to make sure that the content of the article is technically correct. Very often, an article crosses the boundaries between Eclipse projects and so more than one reviewer may be required (i.e. one for each project referenced by the article). When the author and reviewer are done iterating over the content, an editor steps in and puts the final touches on the article. An editor is familiar with the subject area, but need not necessarily be an expert in the field (frankly, it’s great when an editor learns something in the process of editing an article). Editors need to have decent English-language spelling and grammar skills.

Do you have what it takes to be a reviewer or editor? It’s easy to do, just take a look at the bugs open against “Articles” in Eclipse Bugzilla, find an article that interests you, add a comment to the effect of “I’d like to [review | edit] this article”, and then immerse yourself in the role.

While I do relish the prospect of formalizing the role of reviewer and editor, I don’t want to formalize the process too much. Read over what the author has written so far, and provide your feedback as comments via the bug system. If you have any questions about the process, or just want to get your opinions registered about this, please add them to Bug 243486.

To make things more interesting for you, reviewers and editors will now get swag as well. You’ll also get explicit credit for your efforts. And the gratitude of a community.

It’s licensed under the LGPL. Make sure you review that license carefully!