Archive for Adam Williams

Ideas for Further Development

I have a few ideas that I will potentially implement in the near future, but this depends entirely on my direction. Throughout this project I was sorely tempted to move over to WordPress, but due to the amount of work I had already done, I felt it would be a waste. So I stuck with Ruby on Rails, and although I see its huge potential, I would only really be trying to replicate the functionality and brilliance of WordPress as a content management system.

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.

 

Advertisements

Employability

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.

Usability

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

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

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.

Testing

Website Testing Plan

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.

Plagiarism. Naughty, naughty

The term ‘plagiarism’ is usually concerned primarily with academic work in English Language, Humanities and the Arts. However, this too can be applied to newer issues surrounding technology. Given that a vast amount of the Western World’s economy is built upon technological products such as software, mobile phones and other consumer electronics, work must be protected in order to protect the original authors.

As Scott said, the line between plagiarism and inspiration is a fine one. We could completely rip off existing work, giving no credit to the people who took the time to create it and pass it off as our own, but this is dishonest and gets us nowhere. If we do not understand exactly what we are dumping on our page we are learning nothing and merely replicating – throwing more unoriginal content out onto the internet.

We have to start somewhere though. We can’t just sit down and turn onto writing ActionScript or PHP without first experiencing and deconstructing the way existing products function. Many a time I have sat and stared at the source code for a website I have found to be particularly interesting, and this is a great way to learn. We start to notice trends, standards, interesting new ways of achieving what we want. Tutorials are a good starting point for learning ways to create working models for our concepts if you can find one that is specific enough to meet your needs. They give us a framework on which to build something worth putting on the internet.

Some useful tutorial sites I have come across for Ruby on Rails amongst other things:

http://www.tutorialized.com/
http://alistapart.com/
http://www.sitepoint.com/ (not all free, but worth looking at)
http://lynda.com/ (who already have a range of Adobe CS4 tutorials up if you fancy brushing up)

When authoring new websites and code we can be protected with intellectual property laws. Creative Commons is a very accessible way of protecting your work and licencing it for use in the ways you specify. This is highly recommended for anyone who is considering writing plugins, widgets, applications as well as musicans, photographers, authors… the list goes on.

SWOT and PEST

Here’s a quick SWOT and PEST analysis of my project.

SWOT

Strengths

  • Dynamic content production
  • Quick development of web apps
  • User management possibilities

Weaknesses

  • Ruby on Rails is sometimes considered to be labour intensive for the user’s machine
  • Does not work on all web servers

Opportunities

  • Ruby on Rails is a popular new method of development so there is a great deal of support available
  • Speed of development could result in more frequently changing applications

Threats

  • Ruby could fall out of use and web server could stop accommodating for it
  • Twitter planning on migrating away from Ruby on Rails may impact on use of the code

PEST Analysis

Political

  • Artist may produce some controversial work resulting in censorship issues
  • Users may comment inappropriately and cause offence. Again, censorship issues may ensue

Socio-cultural

  • Potential for community building through the website starting from comments pages

Economic

  • Possibility for sales of work through the website
  • Advertising
  • Sponsorship

Technological

  • The vast majority of public have internet access
  • Website will work on most web browsers
  • Website will be accessible in most common resolutions

Jonathan Kelham Portfolio Site: Final Proposal

I plan to work towards building a portfolio site for a local artist named Jonathan Kelham who is a third year Fine Art student in Birmingham. The client needs a website to display a selection of his work including images, videos, a biography, contact page and blog. The purpose of the website is to provide prospective clients and collaborators with an online portfolio of his current and ongoing work and enhance his networking capability as an artist.

The blog will be the main part of the project as I will be building it from scratch using Ruby on Rails. This blog will act like a sketchbook as Jonathan will be able to upload and write about his work in progress which will add more of a dynamic feel to the website. Similar to most blogs, this will have a comments feature that will allow Jonathan to gauge feedback and allow users to contribute to the website with resources, recommendations and opinions. The comments section will initially be hidden, accessible via a link at the foot of the post so as not to distract the user from each post when first viewed.

The sketchbook will be the most significant element in giving the website that dynamic feel that is so important in today’s websites. In general, when a website changes frequently, users will return to it more often which, of course can only be a good thing. After researching the top 100 most visited websites in the UK, it is immediately evident what most if not all of the sites have in common – they all have highly dynamic content.

1.       Google UK
2.       Facebook
3.       Yahoo
4.       Windows Live
5.        YouTube

Also ranking very highly are site such as Flickr, WordPress, Amazon, Wikipedia, etc. Obviously, this website will not be ranked as highly as any of these websites as even the most popular artists hold only a very small corner of the public’s interest on the internet. David Carson is a very popular artist and graphic designer, however his page ranking is a meagre 723,707. Even the controversial Tracy Emin, has a low page ranking of 1,547,901. To add a local slant to the statistics, Birmingham Artists (collection of artwork and biographies for prominent Midlands-based artists) comes in at 5,941,255. Whitecube.com which serves as a directory for contemporary art in London has a relatively respectful traffic rank of:  286,876.

As an artist, he needs exposure in order to make a name for himself within the local art community. For him to have a digital presence would be of great benefit to him as he would be able to refer people to his website while networking amongst Birmingham’s creatives.

The ‘sketchblog’ will be a very important feature of the website as it will serve as a source of news about Jonathan’s work and exhibitions. This is one particular element that most of the art websites I visited have in common – they all contain up-to- date news sections that give information about upcoming events and current activities.

The blog will also have an administration feature where he will be able to upload his own material and manage the content of his blog in a simple but functional manner. The simplicity of this aspect is significant to this client as by his own admission, he is only really competent with technical matters.

The gallery section of the website will be a fairly simple setup, perhaps with some enhanced viewing techniques that give the section more of a tangible feel. Specifically I am speaking about gallery effects; smooth transitions and pleasing enlargements. The gallery will be built again using Ruby on Rails. Works will be organised by medium. Some good examples of galleries that have been built using RoR include:

Eyelook

Gullery (example on http://geoffreygrosenbach.com/)

LogiLogi (working demo) teams up nicely with Lightbox, a Javascript plugin that allows smooth englargements of images with a slideshow style interface when required.

The look and feel of the website as a whole will be quite minimal, but reflective of Jonathan’s work which features a fair amount of white space and natural colour. We have discussed giving the website the feel of paper media without being excessive in use of texture and shadow. Subtlety and understatement is key.

I have completed an initial mockup of the sketchbook page:

Jonathan Kelham - Sketchbook Page (click to enlarge)

Jonathan Kelham - Sketchbook Page (click to enlarge)

As you can see, I have refrained from use of excessive graphical elements so that the page allows the content to be the main feature rather than the site itself.

 I have chosen to use Ruby on Rails mainly because I have been won over by the testimonials from designers and developers who have migrated from the use of PHP in favour of this relatively new framework. Emphasis has been on speed, consistency, manageability and intelligible coding methods. I have been impressed with the existing uses for Ruby on Rails in sites such as Digg, Twitter, 43 Things, and A List Apart to name but a few.

Statistics were gathered from Alexa.com.

Proposal: Portfolio for Local Artist, Jonathan Kelham

I plan to work towards a portfolio site for a local artist named Jonathan Kelham who is a third year Fine Art student in Birmingham. The client needs a website to display a selection of his work including images, videos, a biography, contact page and blog. The blog will be the main part of the project as I will be building it from scratch using Ruby on Rails.

The blog will act like a sketchbook as Jonathan will be able to upload and write about his work in progress which will add more of a dynamic feel to the website. In general, when a website changes frequently, users will return to it more often which of course can only be a good thing. As an artist, he needs exposure in order to make a name for himself within the local art community. For him to have a digital presence would be of great benefit to him as he would be able to refer people to his website while networking amongst Birmingham’s creatives.

The blog will also have an administration feature where he will be able to upload his own material and manage the content of his blog in a simple but functional manner.

The gallery section of the website will be a fairly simple setup, perhaps with some enhanced viewing techniques that give the section more of a tangible feel. Specifically I am speaking about gallery effects; smooth transitions and pleasing enlargements. The gallery will most likely be built again using Ruby on Rails. Works will be organised by medium.

The look and feel of the website will be quite minimal, but reflective of Jonathan’s work which features a fair amount of white space and natural colour. We have discussed giving the website the feel of paper media without being excessive in use of texture and shadow. Subtlety and understatement is key.

 I have chosen to use Ruby on Rails mainly because I have been won over by the testimonials from designers and developers who have migrated from the use of PHP in favour of this relatively new framework. Emphasis has been on speed, consistency, manageability and intelligible coding methods.

Say Hello to Ruby on Rails

I am writing this tutorial with the assumption that you have already installed Ruby on Rails on your computer. Installing Ruby on Rails isn’t exactly the easiest process if you are inexperienced with command-line interfaces, like I am, but I found Lynda’s Essential Ruby on Rails Training to be a huge help.

Before we get started with the Hello World app, you need to install a text editor such as E Text Editor which is available from http://www.e-texteditor.com/ This is just a good tool for editing web pages and great for working with Ruby on Rails. If you’re on a Mac, TextMate is the original inspiration for this program.

Step 1:

First of all you’re going to need to launch Command Prompt from Start > Programs > Accessories > Command Prompt.

Once you have Command Prompt open, navigate to your Ruby on Rails directory (most likely to be C:\Ruby unless you specified otherwise during installation) by typing:

cd c:\ruby

OK, so if your screen command prompt now starts with “C:\Ruby” we can now move on to creating the project.

To create your first project (or any new project for that matter) you need to alter your command line to read:

C:\Ruby rails my_app

This will tell Rails to create a new set of project files as below:

Rails has now created a series of directories and files in your Ruby directory that will be the basis for your application.

Step 2:

The next step is to launch our server. Currently, the web server that ships with Rails is Mongrel.

What we’re going to do now is run a script. You can view the scripts in your project by going to C:\Ruby\my_app\Scripts but as you might guess, the one we are concerned with at the moment is ‘Server’.

To start the server we need to first go to our project directory by typing:

cd my_app

Now we’re in our project folder we can run our server by typing:

ruby script/server

If you see something like the screen adobe, your web server should be up and running. However, just to test this, we need to open our browser and enter:

http://localhost:3000

Hopefully you should see a page like the one below:

If not, just go back and make sure you followed the previous steps correctly.

Step 3:

So, working from the project we generated earlier on in step 1, we are now going to create a controller. The controller is what will be responsible for the actions we request from our application.

To generate a controller, all we need to do is run another script from our scripts directory that we saw earlier. To do this, open another Command Prompt window so as not to interrupt the web server we already have running. Make sure you are in our project folder and alter the command line to read:

C:\Ruby\my_app\ruby script\generate controller Say

If you did this correctly, you should see the following:

What we are doing here is telling RUBY to use the script GENERATE to generate a CONTROLLER called “Say”. As you can see, the script has also created other files, but we’ll worry about those later.

Step 4:

Once we’ve created the controller, we now need to open-up E Text Editor. We can do this from the command line by adding the following line to c:\ruby\my_app in Command Prompt:

e app\controllers\say_controller.rb

You should now see the contents of say_controller.rb in E, and we can go on to edit this to serve some kind of function:

After adding

def hello
end

We can go on to add a VIEW to this controller. A view is exactly what you might think it is. It is the front end of what the user will see and interact with. So what we are going to do now is create a view that we can display in a browser.

The GENERATE script has already created a folder for us within VIEWS, so all we need to do is create the RHTML file. This particular extension is practically the same as HTML, but the ‘R’ at the beginning of the extension implies that the file will include some elements of Ruby on Rails.

The extension .rb as you might guess belongs to Ruby. It implies that the content of the file is PURE Ruby, whereas files such as RHTML only include SOME Ruby.

Click the new file button in the lower-right of your E window and name the file hello.rhtml

We can now edit this view file as we would a normal HTML file. Enter the following (or something similar) into your currently blank hello.rhtml file:

<html>

                <head>

                                <title>Hello World</title>

                </head>

                <body>

                                <p>Hello World!</p>

                </body>

</html>

…and save it.

Now, before we try and view it in our browser we need to restart Mongrel (our web server) by returning to the first Command Prompt window that is running the server and pressing Ctrl+C and then re-launching the server by entering:

ruby script\server

This is necessary in this case to let us view the changes we have made.

Now we can open our browser and go to the address:

http://localhost:3000/say/hello

You should be seeing ‘Hello world!’ in your browser window.

Conclusion

This was a starting block on your way to learning Ruby on Rails and up to now you have learnt how to make a static web page. Of course, RoR is not just for making static web pages, but web applications. This was just a very basic introduction to the framework.

My Current Position

Where am I now?

I have reseached the background and applications of Ruby on Rails and have a loose understanding of how RoR compares to other languages, specifically PHP.

What is the next logical step?

The next logical step in my learning is most likely trying to develop a working product using RoR working from tutorials. I have found various RoR tutorials explaining various applications of the language such as to do lists, blogs, search engines, etc.

Resources

Getting started with Ruby on Rails

Four Days on Rails (PDF)

Top 12 Ruby on Rails Tutorials

Ruby on Rails for Beginners (appears to be more up to date)

Tutorial in Ruby on Rails

Having looked through all of these, it appears that the most up to date and suitible tutorial for me would be the last one, ‘Tutorial in Ruby on Rails’. I’m feeling quite daunted at the moment as most of these tutorials seems to presume you have come from a pretty successful coding background, which I have not. The only coding I use is HTML and CSS at the moment, so this will be a challenge.

Four Days on Rails is a great concept for a tutorial but it appears to be a little out of date. I will however start it and will soon know how out of date it is.

I will document my ‘progress’ here… Eek.

« Previous entries