The Blog

But before completely shunning the idea of continuing along the tracks with Rails (pun intended), I could list a great deal of possibilities in building on the current system. The blog interface could be improved further by using an enhanced GUI allowing users to format their posts with basic HTML or BB code, limiting them to simple formatting options such as inserting images up to a certain size, formatting text, etc. This would be achieved using another plug-in for Rails called RedCloth. This particular enhancement is a more complex formatting engine that allows you to implement simple mark-up such as *bold*  and _italic_.

RSS would be a useful feature to include on the blog so that users do not have to go out of their way to revisit the site for updates. Although Jonathan has a Twitter account where he would post details of his updates, not everyone makes use of this service. RSS and email subscription would be a good way to fill this gap.

The Gallery

The blog aside, I would also like to use a dynamic gallery that allows greater control through a friendly user interface. The gallery I am currently using in the portfolio section, although dynamic, does not allow the user to add captions, or additional information. It does however allow an administrator to add more images to an existing gallery by dropping them into the relevant folder.

Easier Updates

It may also be beneficial to the client to be able to update every page of the website through a user interface similar to that used by WordPress to add a dynamic twist to the entire site. For example, Jonathan’s contact details may change suddenly, and he needs to let his audience know about this.

The reasons I would opt for WordPress:

• It’s already there, and it works very well.
• It is open source and fully-customisable.
• Huge array of useful plugins.
• Great amount of community support.
• Very user friendly from the get-go.
• Not as dependant on hosting capabilities as Ruby on Rails.

The list goes on.

Conclusion

Overall, though I think moving in favour of WordPress would be the best option as it requires less effort on the part of myself and the client in the long-run and would instantly give him more control.

The value of a developer to prospective employers relies quite heavily on the ability to embrace change as standards shift and technologies evolve. I believe an open-minded approach to web development is essential especially with the amount of new platforms emerging on a yearly basis. Two years ago we weren’t aware how big mobile Safari would be or mobile internet in general. The developers behind the apps available for the iPhone have had to adapt their skills in order to become successful in this arena. Objective C isn’t a language that many people are familiar with, however due to its similarity to C++, it has been studied and more importantly, embraced. The same goes for Ruby on Rails. Ruby is said to have quite strong similarities to Perl which is a fairly widely used programming language. After being coupled with Rails, its potential has grown tenfold, now being used in web applications where previously, developers would be using PHP.

On a personal level, the fact I chose to throw myself in at the deep end with a language I have never even SEEN before is perhaps testament to my ability to accept change and force the development of my skills.

On a client-developer level, I feel I have done the project justice, allowing Jonathan access to a wider audience and a platform for self-promotion. He is now able to display his work to anyone who visits the site and is provided with a tool with which to document his professional activity.

Navigation

I have tried to make my project as usable as possible by sticking to the conventional standards of website navigation. The main tool in achieving this is the ever-present navigation bar on the right of the page. Users do not have to scroll around too much to find the navigation buttons which makes the process much quicker. I have also kept my levels to a minimum. The users never find themselves in a deep structure having to go up several levels before they find another area of the site. The deepest they go is in the portfolio section where they are just two levels in (portfolio > collection).

index page

Buttons in the portfolio galleries are very intuitive, displayed merely as forward and backwards arrows which flick between images – a common navigational signifier which I think users are familiar with.

Functions

The blog features some familiar controls also with edit and destroy options at the foot of every post. This only appears when the user is logged-in of course. The login function is hidden from plain sight and accessed by appending the URL with ‘/login’. As there will only ever be a maximum of two different people logging into the site: myself and the client, there is no need for there to be a ‘login’ button on the blog. This would only confuse users into thinking they are able to register for user accounts, which at the moment, they are not.

Forms within the blog are again very standard in format. To go to the ‘new post’ form, the user merely has to find the appropriate link at the very bottom of the page. When creating a new blog post, the user is confronted with only two text fields: ‘Subject’ and ‘Body’. Below this is a ‘Submit’ button. Again, because there will only be two users of this blog, the controls do not have to be terribly obvious as long as they are positioned in a sensible and consistent manner for quick recognition and use.

New Post

Accessibility

I designed my site with a view to simplicity and functionality, and with this comes accessibility. The fact I have used high contrast colouring (black on white) throughout the site means the text is highly readable. I have successfully tested the site using larger font-sizes by adjusting the browser settings and all appears perfectly readable. All of my images include alt tags which means screen readers are able to pick-up the content of the images and navigation links and relay it to disabled users. I have also used appropriate header and paragraph tags to ensure that the textual content conforms to the correct hierarchy. I have seen sites that offer reversed-contrast view which makes the background black and the text yellow to cater for certain types of visual impairment; however there are limits to how far one should go given the purpose of the project.

I am very happy with the final result for many reasons. First of all I think it comes very close to what I originally proposed. I had some doubts when mocking up the wireframes as to whether the horizontal division of the layout would in any way work. I know some themes already use this kind of division, but from what I have seen the content would still be in columns.

Secondly the learning curve for this project has been very steep. Although I don’t intend to release any more WordPress theme in the near future, I will certainly enjoy my experience when it comes to designing custom template files for client’s WordPress sites.

The whole theme is designed according to W3C standards and validate against both CSS 2.1 and XHTML 1.0 Strict. One exception to this is one the single post pages where the comment form is displayed. There is one element in the form attribute that won’t validate: The “aria-required” attribute is not yet supported. Because of accessibility issues (especially in AJAX) I have chosen to leave it in there. In time when HTML 5 gets released properly it will validate, but until then, it won’t.

Bugs

Though I felt the theme was pretty solid when I first released the beta version on the WordPress community site, the testing still revealed a lot of bugs. My CSS though valid, included some CSS 3.0 selectors and values that are not yet supported and these had to be discarded. As they only applied to browsers that supported them I didn’t lose much in removing them.

Another bug was the trackbacks, they would break the layout if the title of the trackback was too long. Solution: use of CSS and a simple PHP if statement to separate the trackbacks from the comments and style them accordingly.

After testing the theme with the widgets and a few plugins, I found that the WP-Gravatar plugin actually caused the layout to break. As this plugin is a third party addon, there wasn’t much I could do about it other than inform my users.

If you are still interested in the theme, go to the official release post!

/Kasper – on Twitter and Delicious

I have split this wrap up into two parts. One about you and one about me, sounds fair right! This first one will be all about what YOU can learn from me and my experience developing my first theme.

First of all: It’s not as difficult as it looks!

The above statement should obviously be seen in the right context. If you are comfortable with WordPress’ template system and have modified or even build your own template files from scratch, then it shouldn’t be a problem. If you have never done anything to your template files and just downloaded and installed them, then you might be better off trying to modify a few templates and learn the codex before creating your own theme. You don’t have to know a lot of PHP, but if you want some specific functionality it does help with some prior knowledge of this language.

The Process

Requirements

The first thing I would have liked to know about before hand was the requirements that WordPress have set out for themes. WordPress simply won’t accept your theme if you don’t meet these. It gives a good foundation to start with to make sure you take everything into account before starting to plan your theme.

Planning

Probably the most important thing; plan everything before you start. You need to have a checklist for everything that needs to be in your theme. You don’t know where your theme is going to be used, so make sure it can handle everything: Nested lists, parent child categories/pages etc. As long as you are aware of it and inform the users of it it’s not a big problem. You save user a lot of time downloading and installing your theme if you just tell them up front.

Design Wireframes/Mockups

This goes hand in hand with the planning stage. Have your checklist besides you while you design your mocks so you can check it off when ever you have included an element in the design. One thing I didn’t include in my mockups was the list of categories and tags on every single post page. It was a design decision to leave them out, but then I saw that WordPress requires them to be there and I had to find a spot for them at a point were I considered the theme done. You want as few of these surprises as possible, otherwise your theme quickly starts to look cluttered. Think about how many ‘different’ pages you want, do you want a different home page and how do you want to display your single post pages and archives, the more uniform all these pages are the easier for you.

The Checklist

Ideally every single element that WordPress uses should be included in your checklist but most importantly are content elements: The elements that authors are likely to use from within the post editor. This includes <ul><li><h1>-<h6><ol><em><a>.

Other important elements include sidebar items, page lists, categories, archive pages and search results. This is a sample of the html page WordPress uses in their theme previewer, if you look through the HTML and use these elements as your checklist you should be covered.

Widgets

Widgets sound like an awful technical term. But it isn’t as complicated as it might appear. As long as you design your theme having in mind that the whole side bar is an unordered list and every single list item is a separate sidebar widget. Every widget is optimized to work with this markup. So just imagine your markup like this and you will be fine (see next paragraph for how to make you theme accept widgets).

<ul id="sidebar">

<li id=”about”>

<h2>About</h2>

<p>This is my blog.</p>

</li>

<li id=”links”>

<h2>Links</h2>

<ul>

<li><a href=”http://example.com”>Example</a></li>

</ul>

</li>

</ul>

Widgetizing Your Theme

If you follow the above example you literally only need to add four lines of code to your templates and your theme is automatically widget ready. First if you haven’t already, create an empty php file in your theme directory and call it functions.php. It should have the following two lines at the top:

<?php

if ( function_exists(‘register_sidebar’) )

register_sidebar();

?>

Then go back to your sidebar and add the following two lines so your sidebar now looks like this:

<ul id=”sidebar”>

<?php if ( !function_exists(‘dynamic_sidebar’)

|| !dynamic_sidebar() ) : ?>

<li id=”about”>

<h2>About</h2>

<p>This is my blog.</p>

</li>

<li id=”links”>

<h2>Links</h2>

<ul>

<li><a href=”http://example.com”>Example</a></li>

</ul>

</li>

</ul>

That’s it your sidebar will accept widgets. You can do more advanced stuff with this markup, you can even add a second sidebar like I have done in my theme or change the markup structure through your functions.php file. Look through this article for more info or take a look at my functions.php file.

/Kasper – on Twitter and Delicious

My original intention was to have a page dedicated to RSS feeds, in which readers gain content quickly and with ease from other similar music web pages. However, I have been having problems when inputting codes into Dreamweaver. I had researched how to create RSS feeds and was planning on inputting the code of a similar working concept, then making my own, necessary in avoiding plagiarism. However, I was having serious coding problems which I genuinely didn’t know how to fix.

Having left his task to last has been yet another downfall on behalf of my poor time management skills. I simply ran out of time, having spent a considerable amount of time on editing table widths and sizes instead (due to problems occurring in this area). This weakness is something I will need to focus on when completing any future design in web and new media.

I am very excited to announce the Collaborate WordPress Theme is now out of Beta an into its 1.1 version. Don’t waste your time, download the theme or go have a look at the live demo page.

Front Page

Single Post

Comments

How to use the Theme

The theme works right out of the box, if you are not familiar with the installation of themes, have a look at the official WordPress article.

The theme uses two separate sidebars.

You will find both sidebars listed in the widgets section of your admin panel. They are named ‘Home Page’ & ‘Post Page’. The first one is for using widgets on your home and archival pages. These will show up underneath the posts dividing the page horizontally. The second one is for using widgets on your individual post pages. This is more like your regular sidebar with the widgets listed vertically at the right underneath each other

The WP-Gravatars Plugin

This plugin is not yet properly supported by WordPress 2.7 and you will have to make some manual modifications if you still want your theme to validate.

I recommend using the WP-Gravatar plugin to show the recent comments on your home page. Just install the plugin, select the widget and display it in your ‘Home Page’ sidebar. BUT! Don’t activate the authors profile widget! This will break the layout. Read the next paragraph to learn how to further customize.

/Kasper – on Twitter and Delicious

I have altered the original mock-up into a more simplistic and clear layout, now having the following pages on my site:

-    News
-    Reviews
-    Releases
-    Features
-    Links
-    RSS

I reduced the number of pages due to poor time management skills on my own behalf. Content is being added to every page, in the forms of images and text. I am trying to keep a fairly even ratio of text / images, necessary in following my proposal adequately.

However, the main issue I am having refers to the PHP elements I am wishing to incorporate. Having researched PHP throughout previous weeks in the course, I felt comfortable with incorporating an area of the hyper text to my site, intending to have code in the middle of my content, keeping the overall per-page overhead down. I had researched that Mac OS X comes with an Apache server as standard, placing files easily in /Library/WebServer/Documents when accessing them on my server. I also learnt that Mac OS X does come with PHP, however the installation lacks a significant quantity of extensions and so it’s necessary to download the complete XAMPP package I had researched previously.

As intended, I downloaded the XAMPP package from here:

http://sourceforge.net/project/showfiles.php?group_id=61776. Choose “XAMPP Mac OS X”

However, when trying to install and run the program, I was receiving technical errors that caused my system to crash consistently. The only problem I could think of was that there may be an issue with having parallels running on my Mac simultaneously. Considering all my design is completed through Dreamweaver on parallels, I had no other option but to disregard my PHP ideas, due to the errors frequently occurring when trying to install the XAMPP package. This is obviously a big disadvantage in terms of what I have proposed for my website. If my time had been managed accordingly, this risk assessment could have perhaps been overcome. However, I shall continue with completion of my website to the best of my abilities.

A testing plan for any website or new media product should really be split into multiple layers. First and foremost, the website should be tested on its main function and ideal path. For example, an e-commerce model should be tested on the ability to a) find the desired product b) add the product to the basket c) finalise payment, and perhaps d) have the product dispatched to the customer. After these factors are tested, it then makes sense to test the lower-level functions and aesthetic continuity. For this reason, the first port of call for testing will be the blog application.

Testers

I hope to be able to gather some beta testers on a variety of different system configurations – a mix of PC and Mac users running older and new versions of operating systems together with a decent spread of browsers. However, in the pre-production stages, this may be a little problematic seeing as Ruby on Rails must be set-up on the users’ machines. I will certainly be getting a selection of users of different abilities to test the system on my own machine using various browsers; of which I currently have installed: Google Chrome, Firefox, Safari and Internet Explorer running Windows Vista. I will also be testing on an iMac running Safari and Firefox with OS X 10.5.5. The benefit of having users test the system in front of me is that I will be able to observe the way the users interact with the site and how long it takes them to accustom themselves to the layout and functionality.

With this in mind, it is important that the intrinsic factors are put on trial first – these being those relevant to the product itself. Extrinsic factors then would be those relating to the system configurations on which the product is being tested.

Intrinsic Factors:

• does the site work?
• do the functions work? (again with the functionality, because it is so basic)
• do the links work?
• are the files present and accounted for?
• are the graphics MIME types correct? (I used to think that this couldn’t be screwed up)

Extrinsic Factors:

Once the intrinsic factors are squared away, then start on the extrinsic points:

• cross-browser and cross-platform compatibility
• clients with cookies disabled
• clients with Javascript disabled
• monitor resolution
• browser sizing
• connection speed differences

(Philosophe.com)

Feedback & Analysis

I will be designing a questionnaire-style form for users to fill-in after they have used the system which will firstly ask a few basic questions about usability: for example;

• Were they able to create a comment one of the posts?
• Were authoring controls hidden from unauthorised users?
• Did all links lead to the correct pages?
• Did the gallery function as the user expected?
• Etc…

I will also then include a less-structured section that asks for users’ opinions on the product broken-up into separate functions such as blog, gallery, contact page, etc. The last part of the testing feedback form will be a general opinion section that allows users to comment on the look and feel of the site.