DocuView - document management system » design

styling forms – the 21st century way

Martin Korych — Thu, 13 Aug 2009 18:09:18 +0000

Based on an amazing article from ZURB I recommend you have a look at I have revisited their technique to:

deliver the same solution in jQuery
use a bit more flexible CSS (at least in my view)
redesign our search box

Up until now we have been using a simple JavaScript solution:

It worked just fine. Displayed the desired value in the input field and on focus it’d replace it with cursor… We use that in combination with:

which would automatically focus on the form’s search field upon loading the document AND:

function trim(string)
{
return string.replace(/^\s+|\s+$/g, '')
}

The sought after not built-in JavaScript trim function (there is a jQuery alternative, see below).

Since then I have also read this article on optimising and styling the submit/search button in IE6/IE7 or generally any browser not supporting text-indent on button elements.

Now for the NEW code

I have used more or less the same code as seen at ZURB.



search DocuView

I have used an id for the form to make the CSS specific, easier to insert and start using immediately. I have to admit I have tried to omit the extra class on the label but the jQuery code stopped working (and frankly I do not know why yet – I’m hoping some of you will help me shed some light on it/I’ll figure out why soon). Anywho…

Coding the form behaviour

I have used relative units (em) to ensure the form scales with the size of the font. Also our tweaked version of Eric Meyer’s Reset CSS is used. The result is acceptably similar in all major browsers (IE7/8, Firefox 3.5, Opera 9, Safari 4, Chrome 2, IE6 is having a problem displaying the submit button as defined – maybe some of you will know how to solve that). In Opera the input field is *slightly* lower than I’d like it to be. I have tried cheating it: converted all the values from relative to fixed (em -> px), using 16px font (.75em = 12px, .5em = 8px, .25em = 4px) + I had to add “invisible” (white) borders to both the search-string input field and the span contained in the label but to no avail. At this point there does not seem to be a way to achieve pixel perfect overlay between the input field and the span (in XHTML Strict). Yet!

Apart from converting the JavaScript from the Prototype to jQuery I have also added validating and styling the label when user deletes the contents of the input field OR loads the page with AutoFill/submitted form values in it. Also instead of using the not-yet-100%-supported opacity/transition all I’m changing is the color of the font in the span.

$(document).ready(function()
{
// Select all textboxes and assign them to an array
var input	=	$('#search-string');
var label	=	$('label.overlay');

if (!$.trim(input.val())	==	'')
{
label.addClass('focus').addClass('hastext');
}
else
{
label.removeClass('focus').removeClass('hastext');
}

// Fade the label back when a field gains focus
input.focus(function()
{
if ($.trim($(this).val())	==	'')
{
label.addClass('focus');
}
else
{
label.addClass('hastext');
}
});

// Fade the label back when the user starts to type
input.keyup(function(e)
{
//	empty? label->focused
if ($.trim($(this).val())	==	'')
{
label.removeClass('hastext').removeClass('focus').addClass('focus');
}
else
{
label.addClass('hastext');
}
});

// Check if a field is empty when the user switches out
input.blur(function()
{
if ($.trim($(this).val())	==	'')
{
label.removeClass('focus').removeClass('hastext');
}
});
});

Don’t forget to include the jQuery library! I have devised a demo and have started implementing this throughout our software. As ZURB warned: do not overuse it. I was happy to find semantically friendlier and in a way much better solution than we have used so far.

Finally: the CSS

body { font-size: 100%; font-family: Helvetica, Arial, sans-serif; line-height: 1.5; }
strong { font-weight: bold; }
#search { width: 20em; color: white; background-color: black; margin: 2em; }
#search div { position: relative; height: 3em; }
#search input { border: 0 none; font-family: Helvetica, Arial, sans-serif; font-size: 100%; }
#search label { position: absolute; left: .5em; top: .5em; width: 19em; height: 2em; background: white; z-index: 1; font-size: 100%; }
#search span { color: black; display: block; padding: .25em 0 0 .25em; border: 0 none; /*border-left: 1px solid white;*/ /*border-top: 2px solid white;*/ }
#search .focus span { color: #ccc; }
#search .hastext span { color: white; }
#search #search-string { position: absolute; z-index: 10; top: .5em; left: .5em; width: 87%; height: 2em; background: none; padding: .25em 0 0 .25em; /*border-top: 2px solid white;*/ }
#search #search-submit { background: transparent url(http://img.docuview.co.uk/sprite/search.png) no-repeat center center; height: 100%; width: 13%; font-size: 0; text-indent: -9999px; line-height: 0; display: block; position: absolute; top: 0; right: 0; z-index: 10; overflow: hidden; }

Thank you, ZURB guys, for the inspiration, I absolutely love the idea! I hope you find the implementation as useful as I have.

CSS line-height

Martin Korych — Thu, 16 Jul 2009 11:07:53 +0000

I do not normally repost or write about someone else’s blogs, but this one is far beyond what I consider useful and I wanted to share it. Pasting the link here so even I can come back to it in the future is far less than I’d like for such an article, but I’ll start with spreading the word. Educate, enlighten, encourage to explore, you’re ticking all my boxes!

Well, here goes. A class, superb article on CSS line-height. We’re definitely testing and implementing this as of the next version of DocuView.

fluid CSS steps – this is how it’s done :)

Martin Korych — Sun, 12 Jul 2009 01:06:28 +0000

I have had Cody Lindley’s technique for CSS steps in the back of my head for soooo long and finally got around making my own version of it. My aim was to create a flexible fluid version of Lindley’s wizard menu. And I’ve succeeded. Here’s how:

Approach

Whether you decide to use

as well. In my example I have used

Consider how many steps you are going to use in your CSS steps (wizard menu): 2, 3, 4, 5… more? Is more really necessary? Two, four and five steps are easy. You are going to end up with

two steps both 50% wide (class “two_steps”)
four steps each 25% wide (class “four_steps”)
five steps each 20% wide (class “five_steps”)

But what about 3? Since a floating point (decimals) is not 100% supported by all browsers and 33.3 × 3 ≠ 100, we have to cheat a little. I have decided to give the current element a width of 34%, leaving the other two at 33% (+ class “three_steps”). To users’ eye hardly noticeable, to me achieving what I set out to do in the first place. You could use similar technique when working with 6 step menu: 5×16% + 1×20% OR 5×17% + 1×15%.

/*	STEPS WIDTH	*/
#progress-bar.two_steps li { width: 50%; }
#progress-bar.three_steps li { width: 33%; }
#progress-bar.three_steps .current { width: 34%; }
#progress-bar.four_steps li { width: 25%; }
#progress-bar.five_steps li { width: 20%; }

Yes, one could argue I could simplify by omitting the #progress-bar, the choice is yours.

No matter how many steps you are using there are 5 (essentially 4) classes utilised: “current”, “previous”, “done”, “last” and empty.

current – for the active element
previous – for the element just completed – preceding immediately the “current” class
done – for the element dealt with two (or more) steps back – for the element preceding immediately the “previous” class
last – for the very last element – used in conjunction with current

Here is the CSS for the whole progress bar, I’ll go through each line separately:

/*	PROGRESS BAR	*/
#progress-bar { text-transform: capitalize; margin-bottom: .25em; height: 3.5em; }
#progress-bar li { float: left; height: 3.5em; color: #ccc; background-color: #efefef; background-image: url(../img/steps/default.png); background-position: right center; background-repeat: no-repeat; }
#progress-bar a { display: block; padding: .25em; height: 3.5em; line-height: 150%; text-decoration: none; }
#progress-bar em { display: block; font-style: normal; font-weight: bold; }
#progress-bar span { display: block; }

#progress-bar .current { color: white; background-color: #369; background-image: url(../img/steps/current.png);  }
#progress-bar .current a { color: white; }
#progress-bar .last { background-image: none; }
#progress-bar .done { color: white; background-color: #c8e9ed; background-image: url(../img/steps/done.png); }
#progress-bar .previous { color: white; background-color: #c8e9ed; background-image: url(../img/steps/previous.png); }

I have sat down earlier and thought of the colours my progress bar is going to be. I wanted grey for bits that have not happened yet, the teasing (used #efefef as it is very light yet recognised as grey with #ccc for the colour of the text). Something stronger, bolder for the current element: #369, text white. And the previous and dealt-with parts: lighter blue perhaps, text white too? I used #c8e9ed as the background colour.

At this point I should maybe mention the four different background images we will be using to create the illusion of one step leading to another. According to the classes mentioned before I created four images that I will use as backgrounds of the li – list items. Here they are:

The first one: default – as in the first step all steps but the first are yet to happen, the two transitions we will be witnessing is between the elements with grey background and the current element with the dark-blue background into the grey again. Every step after the current one – unless the current is the last step – is a little unknown (blue into grey) – the blend is obvious and easy. In the case where current IS the last step we combine it with the “last” class – which disables the background image yet preserves the background colour. The “previous” class transitions from lighter blue (has happened) immediately into “current” element – light-blue into dark-blue transition. And the last: “done”: both done and previous steps have happened, hence only a transition between light-blue AND light-blue. Easy, right?

Since there is always going to be only one instance of the progress bar and since an id has more gravity as a selector than a class I named my little experiment “progress-bar”. I suppose the only important rule in the first line is the height of the whole thing. If you are trying to fit in more: change it.

Rather than using “li { display: inline; }” I floated the list items, the height matches the parent element and the important bit: the background. Since we are assigning the aforementioned background arrows to

s themselves, rather than explicitly writing the rule every time it occurs I defined the background-position and background-repeat for all the elements here. It doesn’t change throughout the steps and saves couple of bytes No really..

Used (emphasis) and to describe the steps, rather than floating and clearing each other I used display: block on both. The rest deals with each step by changing the default background and the colour of the text to allow users to easily distinguish between what has happened and what is still ahead. The .current a { color: white; } rule is there to overwrite an existing one higher in the stylesheet, you might choose to leave it out.

As mentioned before: striving for semantically correct markup I have used
– ordered list – they are steps in the end that happen in a particular order – so it only makes sense to use that. There is a link within each li, note that NOT ALL OF THE LINKS have a “href” attribute. The code for the first step is fairly simple – I have used an example from our day-to-day programming:

step one »description

step two »members

step three »folder access

step four »confirmation

This is what it the first step looks like formatted in real life:

Second step:

Third step:

Fourth step:

Voila!

Believe it or not I have been searching for a similar solution all over the internet on and off for over a year. As I mentioned earlier the main credit goes to Cody, his awesome solution inspired me in the first place. I was excited implementing the solution in the latest DocuView and testing: successfully in IE6+ (hell) – Win, FF 2+ Win & Mac, Safari 3+ Win & Mac, Chrome 1+ Win and lets not forget Opera 9.5+ both Win & Mac.

If you have any suggestions, if you think I could have done it easier or differently or if this too is what you have been looking for leave me a comment below.

Now I’m onto turning this (the MAC-like dock that is) into a semantically correct solution, one that works in IE6. And when I do, you will hear about it here. Make sure you subscribe to our feed to get the all the updates!

At both W this point I should maybe mention the four different background images we will be using to create the illusion of one step leading to another.

FAMFAMFAM alternative – found it!?

Martin Korych — Sat, 06 Jun 2009 11:44:48 +0000

I love FAMFAMFAM. You see it everywhere on the internet, mostly because: it is sooooo good. But it is also very very out of date (read: has not been updated since March 2006 – so over three years now) hence quite limiting. I have tried contacting Mark James on several occasions but to no avail. I’d love an update, I’d love little Twitter and Skype icons, I’d love GUI icons, I’d love an up-to-date set of icons that would suit our developing needs. And I think I found it!

It is of japanese origin. It is updated often! It contains more icons than FAMFAMFAM. It has a shadow AND a non-shadow version. And it is called Fugue (www.pinvoke.com)

16×16 pixel PNG icons that seem to be the new FAMFAMFAM immediately striked me. 2037 reasons to look into DocuView’s CSS again Than you, Yusuke Kamiyamane.

BTW – whilst you’re at Yusuke’s website, do check out the free fonts and the Diagona icons he offers too!

Adobe BrowserLab – preview your project in *any* browser/OS

Martin Korych — Thu, 04 Jun 2009 08:04:45 +0000

This morning I have stumbled upon Adobe BrowserLab. It promises to deliver the exact renderings of our websites and projects on leading browsers and operating systems. It enables us to compare our designs and consider how they might appeal to our clients.

We pride ourselves in delivering content and software working flawlessly on any combination of the above yet this tool could help us make sure that remains the case in the future too.

BTW – have you dropped supporting IE6 yet? Can you?

PDF on-the-fly

Martin Korych — Tue, 18 Nov 2008 14:54:44 +0000

We have done achieved it. Worked on it for a long time and finally cracked generating/converting Microsoft Office documents as well as other formats into PDF using OpenOffice. Not only is the conversion much faster and more accurate, even embedded Visio objects get translated as opposed to previous version, we’re now working on superimposing an additional layer on printing the document that would be customisable and only visible on print.

The aim is to offer a watermark saying for instance: “This is now an uncontrolled document printed from DocuView on [date] [time]. For the latest version please login to DocuView.”

More details soon, we’re currently redesigning our website.

DocuView – where we are now

Martin Korych — Tue, 29 Jul 2008 14:34:30 +0000

We have entered the finishing stage of our planned development of DocuView, we’re intending to release a stable version in the following weeks and start the marketing campaigns and advertising.

I’d like to focus on the key functionality and features of DocuView today, give you a bit of a teaser and hope for your feedback:

protect your master documents (whether created in Microsoft Office^TM or OpenOffice^TM) – documents get converted to PDF (non-editable, portable, cross platform) format

manage users through security groups, grant access privileges to folders and documents contained, even system areas (reports, management), create self contained environments that allow users to interact and create/manage documents themselves

utilising latest technology (open-source server side programming language, database backend to centralise data and resources, tested and working in ALL major browsers (IE6+, Firefox, Safari, Opera)

operating-system independent environment, that looks, feels and performs the same whether you’re on Mac, Linux or Windows

constantly under development (and testing) – by re-investing revenue generated – introducing new functionality and enhancing user experience through familiar features and intuitive environment and to make sure we stay ahead of the game and up-to-date with current technologies, strategies and trends

document tagging for fast and accurate searching (and yes, we’re looking into document indexing based on content)

wide spectrum of formats supported (MS Word and Excel documents, PDF, scans (TIFF, JPEG, GIF, PNG), OpenOffice documents) and growing by the day

Web 2.0 technology: user-friendly, intuitive, easy to work with and… nice to look at

DocuView has been developed primarily to meet the requirements of aviation industry, document approving requirements and is capable of dealing with multiple Quality Officers approving documents for several departments independently. We’re currently looking into train’s, ship’s, car’s, power station’s and other industries’ requirements. That’s not to say you wouldn’t be able to use it in your design office, production company, manufacturing premises, as a supplier, landlord, restaurant manager… you name it. The flexibility and versatility of the system doesn’t limit the use of DocuView to any industry at all.

In the following posts I’ll explaining the features of DocuView in more depth. We love our documents, we love DocuView. And we are bringing it to you!