It would be nice to say that at this point, the application was finished. The design brief has been satisfied, and the main user has looked over the production instance and expressed her satisfaction. Rory has taken a simple list of contacts and converted it into an application that is available throughout the organization; not just to view, but also for others to add and modify contact information. He has taken steps to ensure that the system is reliable, performs reasonably well, and has even gone to the trouble of developing a backup regime. Anyone would think the project was finished. That is anyone who has not put a new application in front of a group of users.
In this chapter, we will concentrate on the tools we can use to improve the user experience. These include providing links into the application, providing search tools, enhancements in the user interface, and providing help to the users.
It is the end of the week and time for Rory to present the new application to Ken. Rory is asked to demonstrate the new application to Ken on his PC. At first, the demonstration goes well, especially when Ken realizes how easy it is to access with no need to install a new application on his system.
Then Ken raises the first issue. "How am I going to get back to that web page?". Rory's first thought is to add a bookmark, but when he opens Ken's bookmarks his eyes are assaulted by a cascade of disorganized bookmarks. He should have realized that they would not be well managed when he saw Ken's desktop was packed full of shortcuts to applications and documents.
In general, users hate having to remember the URL to an application. So, if you want users to use your application regularly, you need to give them an easy way in.
The URL Rory used to access the application during the demonstration was:
http://intranet.company.local/people/list
In fact, he missed a trick here. Because there is an index action in the people controller, and as discussed in Chapter 5, Rails will use that action to return content to the browser if no action is specified in the URL. So, Rory could have used:
http://intranet.company.local/people
However, he could have simplified the URL further still, by modifying the application's routes. These are modified via /config/routes.rb. Rory could add the following to simplify the entry URL further still:
map.connect '', :controller => "people"
This would simplify the entry URL to a pathless default action of:
http://intranet.company.local
However, before this works, Rory must first, either rename or delete the file /public/index.html, as Rails will always try to return this page if no path to a controller is specified in the URL. Only after it has failed to find an index.html document, will it look in routes.rb for an alternative.
The map.connect entry has to be inserted between:
ActionController::Routing::Routes.draw do |map|
...and the final
end
The simplest syntax to use with the route is:
map.connect 'url_path', :controller => 'controller_name', :action => 'action_name'
Where url_path is the part of the URL that is to be entered after the basic web server address, so that Rory could add a path:
map.connect 'sales_contacts', :controller => 'people', :action => 'list'
This would allow him to use this URL to access the list of people:
http://intranet.company.local/sales_contacts
There is a problem with making the pathless default action point at a particular part of your application: it does not scale well. It is fine when the application is simple and has a single main role. In this situation, having a single path into the application works fine. However, as applications grow, more functions will be added and a single entry looses its usefulness.
The solution is to create a home page, which contains links to different parts of our application. As we develop our intranet we can add links on our homepage, to each new function or application.
Get the home page right and users will use it as their default home page. To achieve that we will need three things:
- Provide links to external resources that the users use regularly.
- A simple, clear design that is easy to navigate.
- The fastest possible page load.
The home page needs a clear layout with a number of well chosen links. It also needs to appear as soon as the browser opens. If users start to detect that a home page is delaying their access to web resources, they will stop using it. Users will put up with a short delay while going to a specific part of an application, but they will not tolerate a delay that occurs every time they open their browser.
The easiest way to ensure that the page loads as quickly as possible is to make it a static HTML page. Any dynamic content will increase the time the page takes to load. A user's home page is the one place, in my opinion, where the speed of static content outweighs the easy maintenance and flexibility of dynamic content. We can use CSS to control the layout of the page, and thereby simplify the HTML code and make it easier to maintain.
If we already have an intranet or are hosting our Rails application behind an Apache server, we can host the page within our existing static content. Another option is to host it within our Rails application, and there is already a place provided for it. We can name the home page index.html and put it into our Rails application's public folder, replacing the existing file of that name. We then put the CSS file for this page in the /public/stylesheets folder and update the path in our index.html to suit. Remove any entries in routes.rb of the type:
map.connect '', :controller => "controller_name"
Then, if we type the basic path to our server into our browser, we'll be taken to our new home page. For Rory this means that he accesses a home page by entering http://intranet.company.local in his browser.
