DocuView - document management system » docuview

customise the default size of avatars in WordPress 2.8+

Martin Korych — Mon, 31 Aug 2009 17:59:03 +0000

You know the drill: backup, upgrade WordPress, check plugin compatibility, verify everything is up and running and… reapply your hacks to the core of WP. I have talked about displaying the post excerpt in the recent posts widget few weeks ago, today I’m going to talk about resizing the Avatar image file displayed in comments.

So you’ve just finished upgrading, everything went smooth and you now have some time to amend the core of WordPress to accommodate for the hacks and workarounds you have implemented over the time. You have styled, laid out and customised your comments, you have changed the default size of Gravatar, Avatar or any other user pictures you display only to find them going back to default (32px × 32px) as soon as you upgrade.

Worry not! In order to change it back to what it was, head to: “wp-includes/comment-template”, locate line #1322 (function wp_list_comments()) and change the defaults array value (“avatar_size”) from 32 to anything you like (we use 50px), so the result will read:

$defaults = array('walker' => null, 'max_depth' => '', 'style' => 'ul', 'callback' => null, 'end-callback' => null, 'type' => 'all',
'page' => '', 'per_page' => '', 'avatar_size' => 50, 'reverse_top_level' => null, 'reverse_children' => '');

And zet is zit. Save and refresh your comments page and enjoy, your user icons and images are exactly big (or small) as intended.

Helpful? Drop me a line here.

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.

Microsoft Office 2010 (codename v14) in the wild

Martin Korych — Mon, 13 Jul 2009 00:03:19 +0000

A trailer for a movie that does not even exist came out few days ago. And then I came across a link to a BETA Technical Preview of the new Office 2010. Just wanted to let you know that we will commence testing pretty soon and will prepare DocuView to be able to translate the new Office 2010 documents – when it launches – into PDF.

Currently we handle all Office 97-2007 Word (*.doc, *.docx) + Word containing Visio, Excel (*.xls, *.xslx), text files (*.txt), rich text format (*.rtf), OpenOffice 1+ all formats, image files (*.png, *.jpeg/jpg, *.gif, *.bmp…). We’re adding support for media files (wav, mp3, mp4, swf, mov) over the next three months using our bespoke media player. We’re also currently testing Microsoft Works and various Mac/Linux related document formats.

We will be releasing a comprehensive list of all document formats supported before the end of July – so stay tuned!

Printing support throughout modern browsers

Martin Korych — Sun, 12 Jul 2009 16:54:23 +0000

Quite a lot of effort went into our print stylesheet of DocuView based on various superb articles on Smashing Magazine or A List Apart. We boldly advertise the fact that we support all major browsers (even the unsafe, unfriendly and ancient ones -yes IE6, I’m talking about you!) – but to my surprise after thorough testing on both Mac and Windows I have to consider including a disclaimer in our marketing: “we cannot guarantee the results in Safari, Chrome and Opera, neither in Windows nor Mac OS”.

At this point I am still hoping we are doing something wrong, we are overlooking something – to be honest it mainly affects the printing of distribution lists – as we do not experience our users to be printing out anything else other than the documents… I have read up about css property “page-break-after” and its usage and support throughout various browsers and am achieving the desired effect in all Internet Explorers (6+) and in all Firefoxes (Mac & Win), but because we cannot force printing background graphics, images or backgrounds in Safari nor Chrome (Opera seems to offer a little not-so-clear-what-they-meant-by-that option) and we are not expicitly given the option to preview what we’re about to print we cannot debug and tweak 100%.

Googling for a solution didn’t bring desired results either, so until we fix it (or 100% confirm it is not out our fault) we will have to discourage the use of the aforementioned browsers if you intend to print out of DocuView anything else but the documents. Are you experiencing the same or is it solely only our problem?

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!