Progress of new fsfe.org website design

Posted by samtuke on 0

At the FSFE web sprint on the weekend before last I focused on implementing a new design for fsfe.org. The design will provide a fresh new appearance for all fsfe.org pages (it wont affect other FSFE sites like fellowship or planet; that will come later), and is the result of more than a year of discussion and planning.

Since I began working full time at FSFE’s Berlin office three months ago, I have been working towards getting a fresh look for the site, and replacing the current design which has desperately needed attention since before I first joined the organisation in 2009.

In September and early October I created several detailed vector based design proposals, based upon Andreas Tolf Tolfsen’s inspired ‘ribbon’ themed mock-ups. New site wide menus, a theme-integrated identi.ca feed, and interactive rotation-animated campaign banners were some of the innovations that I showcased in my submissions.

Together, Andreas and I worked out solutions to usability problems arising from new site features, and responded to reactions from community members. Aided by astute and encouraging feedback from Reinhard Muller, I worked feverishly in the run up to the web sprint to create a design that was as progressive as possible, whilst remaining sufficiently conservative to maintain consensus amongst web team members.

Whilst other team members worked on fixing existing bugs with the site and the new build system (which handles generation of our thousands of translations, amongst other things), I worked on turning the new design into the code of fsfe.org for the first time. The schedule, which I published two days before the sprint, stated the implementation of the new design as the number one priority.

Although I had hoped to have the design implemented and approved for launch by the end of the week following the sprint, it turned out to be more work than I had anticipated. I had also not expected to be the only one working on this task, which, aside from a few appreciated commits made by Andreas, turned out to be the case. As a result, nearly two weeks after the sprint fsfe.org remains its old ugly self. But not for long.

Approximately 85% of the front page, 95% of generic content pages, and 70% of specialised pages (such as ‘about’, ‘contribute’, ‘shop’ etc.) are complete. Since the sprint I have been squeezing in a few rushed minutes here and there between other tasks, and the site is finally nearing completion.

Once my implementation is ready on the ‘design’ branch of the web SVN. I’ll send it to the FSFE team mailing-list for approval, which I trust it shall speedily receive. Then will come the task of merging it with the current ‘trunk’ version of the website, at which point all my changes and improvements will, finally, be publicly visible.

Web sprint begins

Posted by samtuke on 0

This morning the FSFE web sprint began. Last night we met and went to dinner at a very traditional (and remarkably cheap) Turkish restaurant, where we sat cross legged in the back room on patterned cushions and carpets, and ate a variety of stuffed flat breads, vine leaves, white cheese and salad. The only item not to my taste was a popular Turkish yoghurt drink; its salty, milk taste wasn’t to my liking.

After a meeting this morning, and a recap of the evolution of the FSFE website through the ages (since 2000) up to this point, work got under way. The room is now abuzz with merry typing.

I’m on freenode’s #fsfe-web channel, and signed in to jabber (samtuke@jabber.fsfe.org) if you want to talk web or contribute 🙂

Web Fridays

Posted by samtuke on 0

As part of an increased focus on improving FSFE’s websites, each Friday afternoon from this point on will be dedicated to working through issues and improvements to these services.

FSFE’s Berlin office staff, in addition to key members of the web team, will be available on the fellowship jabber channel for live discussion about web issues.

Web Fridays are a great opportunity to work along side other FSFE staff and fellows, and are a good time to learn about how to contribute code and improvements to our websites.

To get involved:

join fellowship@conference.jabber.fsfe.org (fellowship chat channel)

join https://mail.fsfeurope.org/mailman/listinfo/web (web team mailing list)

register at https://trac.fsfe.org/fsfe-web (technical issue tracker)

PDF Readers: Getting judgemental

Posted by samtuke on 0

During FSFE’s recent campaign to stop governments advertising proprietary PDF readers, a common question was raised by the public in emails and comments. “Can Free Software PDF readers match up to Adobe Acrobat Reader?” they ask. The implication of this question is that promoting alternatives to Adobe, whether they be Free Software (FS) or not, is only reasonable if they are ‘as good as’ (e.g. file compatible and feature feature identical with) Acrobat Reader.

This view undermines the PDF standard however, and falsely defines what PDF is in terms Adobe’s implementation.

Although PDF is an ISO standard, how PDF is used is not standardised. Thanks to non-conforming proprietary PDF editing software, the Internet is awash with PDF files which do not conform to any version of the ISO PDF standard. When FS PDF readers cannot open these non-standard files, they are perceived as inferior.

This is particularly so in the case of PDF documents supplied by government organisations. Citizens are understandably frustrated when they cannot properly view important information from their state, submit tax, or registration information using the PDF forms that they have been provided with. If switching to Adobe’s reader solves their problems, then FS readers are blamed. Nobody asks about whether the file is valid PDF.

So how can FSFE encourage wider use of FS readers in good faith when the expectation is that PDF documents will work more reliably with Acrobat Reader?

The acronym PDF means something specific. It is a file format, and it is amongst a tiny number that has been formally standardised. PDF means the PDF standard. When companies release PDF software that intentionally generates files that do not conform to that standard, they are distancing themselves from PDF. This is exactly what Adobe is doing each time it releases a new version of Acrobat with extended functionality not supported by the PDF standard.

Corrupting standards is a long established practice, and popular amongst big software players. It is a shame however when governments unintentionally support the corruption of standards by providing documents with a .pdf extension which do not conform to PDF standards. When a state employee creates a new file in Acrobat Pro, no warning messages will appear to alert them to the fact that they are about to break the internationally agreed definition of PDF.

When a user downloads such a file, there is no immediate way of telling whether it conforms to standards either. Many naturally assume that because the file is .pdf, it is a valid document in PDF format, and that any reader that does not open it correctly must therefore not be a good PDF reader.

A far more accurate way to assess the success or failure of a PDF reader however would be based on the extent its implementation of PDF standards. It isn’t reasonable to judge an application based upon how well it works with something that it wasn’t designed to accommodate – namely a non-standards compliant PDF file.

Even Adobe’s reader fails when measured by such unfair criteria – Acrobat can’t open non-compliant files any better than FS readers can when they don’t have the advantage of having generated them themselves. In such cases the company ironically becomes the victim of their own game: on more than one occasion I’ve had to assist a friend in opening a PDF document using Free Software because Acrobat was unable to do so.

What is less obvious is that we should take a similar approach to PDF files. When FS readers are criticised because of incompatibility with non-compliant PDF documents, the fault of the file should be highlighted, both to the user, and to the organisation from which the publication originated.

Therefore the question should not be “Can Free Software PDF readers match up to Adobe Acrobat Reader?” but rather “do any Free Software PDF readers fully implement ISO PDF standards?”, and in cases of specific documents: “does this file conform to ISO PDF standards? If not, why not?”.

Adobe’s implementation of PDF is far from perfect. If we judge FS implementations of PDF according to their similarity to Acrobat Reader then they will always come up short. Instead of chasing Adobe’s definition, we should all be chasing ISO’s definition, and this includes the governments who publish documents in PDF.

New FSCONS 2010 web button

Posted by samtuke on 0

I’ve published a new badge/button for attendees of this year’s Free Society Conference in Gothenburg. I added it to the new promotional materials page of the FSCONS.org website. Expect some leaflets to follow soon. Enjoy!

I'm going to FSCONS 2010!

Building a better collaborative editorial work-flow platform

Posted by samtuke on 0

As coordinator of the new editorial team at FSFE, I have recently been working to put in place a new system for the management of tasks and documents for publication on the foundation’s website. Below is a brief update of progress, and my current thoughts on the subject.

After lengthy meetings with other editors, and members of other FSFE teams, I’ve come to the conclusion that the team needs a new system for managing changes to content, and I have put together a list of required features for whatever work-flow system we use.

Why do we need a work-flow system, you may ask. There are several good reasons for this, the most important ones being that a greater level of automation, accountability, and organisation is required in the process by which existing content is edited, and new content is produced.

Up to this point, mailing lists have been utilised for most discussion about editorial decisions. Mailing lists have their benefits, but a mailman-based system is sorely lacking in facilities for fine tuning, monitoring, and generally managing communications and content submissions.

The editors team requires a slick, clear platform, that does absolutely the maximum possible to reduce the requirement for manual admin and management. Basically, as a team we need to focus on content not administration. Each click required to publish something on FSFE drains enthusiasm, motivation, and goodwill, and reduces the amount of participation and community involvement that we can expect.

My initial thought was that there may be an existing Free Software solution to the problems outlined above. I had hoped there would be a suitable, widely used and well supported open platform for collaborative textual content production befitting an editorial team. Sadly I was unable to find such a thing, and was unable to locate a model even in the commercial sphere of software.

While I am aware of applications like ProcessMaker, In my view, what the team needs is not a generic work-flow system that can be heavily customised and tweaked using cumbersome interfaces to do more or less what we need. I don’t want to start with something generic and mould it to something specific. Such solutions tend to be commercial, and very time-consuming to arrange and manage.

Instead I focused my investigation on existing bug tracking packages. There are already many well-established bug tracking systems, which are well maintained and documented, with a wide community of developers. Presently I am anticipating using a modified version of MantisBT; potentially writing plug-ins as the need arises. After discussion with the developer of Mantis’ plug-in system I’m hopeful that the platform can remain simple enough for everyday use, what are the same time meeting the varying needs of the editorial team.

Critical features will include things like notifications of an unassigned piece of work nearing its deadline, the ability of community members to assign themselves tasks and projects, facilities for submitting content ideas and proposals, and a very quick non-technical procedure for publishing documents at FSFE.org.

I’m currently working with the FSFE server administrator to get the bones of the work-flow system in place, so that customisation can begin. I also have draft guidelines being produced this week to provide a reference for style and quality of English.

I warmly encourage anybody interested in being involved with English content on FSFE.org to sign up to the editors team mailing list. Whilst the mailing list may not be the team’s primary medium of communication in future, for the time being it can act as a platform for people who wish to express interest and initiate their involvement.

For the time being I don’t plan to make any announcements to other mailing lists or communities as the mechanics of the team are not yet operational. However, over the next few weeks this situation should change, and when it does I shall be working to get as many people involved as possible in working together to improve the quality and the quantity of content available from the Free Software Foundation Europe.