The surprising thing about

Share this article

,at least to me anyway, is although I’m using it using it fairly frequently, I hardly ever visit the web site itself (or at least that’s how it looks when adding a bookmark).

That’s possible thanks to Firefox and two extensions – (adds a context menu on right clicking a page, to post to among other things) and foxylicious (allows you to view your favorites from your bookmarks menu). Combined the extensions eliminate at least 50% of the clicks / keystrokes I need to work with the normal UI.

This goes back to what I was mumbling on about in Seperating Browser from Resource.

So how does that translate to an application like DokuWiki? Messing around with it a little, creating some pages, strikes me how superfluous those buttons are (Edit Page, Show Revisions etc.).

If, instead, you could right click on any page and see a menu something like;

. DokuWiki

.. Edit Page

.. View Revisions

.. Backlinks

…these could take you to the relevant page / form (perhaps opening a new tab or a popup). Also if you had a bookmarks folder that showed you the Recent Changes as well as the index that’s basically eliminated all those buttons except the search (which could easily become a search plugin). What’s left is only the resource itself – the wiki page.

That simple analysis suggests the code for a Dokuwiki Firefox extension wouldn’t be a great deal different from the extensions… Would it work for other online applications? What about Sitepoint’s forums?

Now taking a leap into the unknown… can we get to the point generating a Firefox XPI installer with PHP, which is primed to add the context menus which in turn popup the necessary tools for working with a site / web app? We’ve got RAP and PEAR::Archive_Tar (see Davey’s PHAR proposal for ideas).

The gain, as I see it, is the user experience gets better / quicker and website development get’s a lot easier – no more thinking about things like MVC. You “simply” build the pages for viewing content then the tools for stuff like editing the content are implemented as standalone scripts with an independent UI.

Harry FuecksHarry Fuecks
View Author

Harry Fuecks is the Engineering Project Lead at Tamedia and formerly the Head of Engineering at Squirro. He is a data-driven facilitator, leader, coach and specializes in line management, hiring software engineers, analytics, mobile, and marketing. Harry also enjoys writing and you can read his articles on SitePoint and Medium.

Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week
Loading form