Longtime 42 Solutions client Manhattan Mini Storage saw the changing landscape in the way people were accessing sites and doing business and realized that they needed to “go mobile” or risk losing business to those who did.

But how does one go mobile?

The existing Manhattan Mini Storage website consists of hundreds of pages and a dozen sections, all designed for the modern desktop browser. Should the entire site be translated? And, if so, how?

In consultation with 42 Solutions, Manhattan Mini Storage determined that the mobile website would be stripped down just to its sales channel, allowing customers to find available storage near their neighborhoods and reserve them online. Now it was up to 42 Solutions to figure out the rest.

The Challenge

Building a mobile version of the Manhattan Mini Storage sales channel provided an interesting challenge for both 42 Solutions’ design and technology teams. How best to boil down a process that was already so simple into something optimized for the handheld experience?

Working with Mini Storage partner Ready Set Rocket, the 42 design team needed to recreate the experience of a mobile app through a device’s web browser, optimized to the lower resolution and screen size.

The technology team, at the same time, had to isolate what information was necessary for the completion of the workflow and ensure that that, and only that, was being communicated at the proper time to ensure the lightest browsing experience possible.

All of the customer leads and reporting data collected along the way in the standard flow also had to continue being captured in the mobile to ensure the sales team had the most to work with with following up with potential customers.

It was a website for small devices but the challenges were big ones.

The Process

Despite the tranquil surface, the workflow was actually rather complex.

To ensure that no unnecessary work was done and to make sure nothing was done twice, 42 Solutions analyzed the problem and broke it into discreet pieces of functionality. Certain elements would be handled on the server side through the use of RESTful calls while others would take place on the client side.

Individual design elements were identified and areas of reuse noted.

Data calls were planned out carefully to ensure no call was made unless absolutely necessary.

Only once everything was broken up did we begin deciding who would put what together. Tasks were split between design and technology to ensure everyone was assigned tasks for what they did best. And in the end, it worked.

Working with a series of mockups generated by Ready Set Rocket, the 42 Solutions design team turned them into mobile reality through the magic of HTML5. Separating all of the different “pages” into discreet flows, our design team made the entire process happen through the use of a single HTML page. By hiding and showing the relevant sections, the flow would mimic the Look & Feel of any iPhone or mobile application installed on their device.

At the same time, our technology team was writing a series of RESTful APIs to be called from within the application to return data, makes reservations, or generate sales leads.

Where design met technology was in the JavaScript that glued the entire project together.

Unlike many shops were designers stick to their Photoshop and everything else is handled by the programmers, the designers at 42 Solutions aren’t afraid to muck about in the code. Beyond just rendering the assets required, our designers created the actual HTML of the page then created “shell” JavaScript functions to show or hide content sections according to where the customer was in the flow.

The result was an entirely “functional” mobile site that our client could step through before a single AJAX call had been implemented. This was a massive benefit to the project that allowed elements to be tweaked and the flow to be modified without interrupting the work of the programmers.

When the RESTful API’s were finished, the 42 Solutions technology team then inserted calls to them within the shell functions that already existed and manipulated the content displayed based upon what was returned. Thus, the integration between technology and design occurred in a matter of days and not weeks.

The Result

One month from the time the mobile project was handed to 42 Solutions, the mobile version of Manhattan Mini Storage went live, allowing millions of New Yorkers to search and reserve storage rooms in their neighborhoods and around the city online with their mobile devices.

And with an interface utilizing many of the native HTML extensions available for mobile browsers, the interface is as fast and familiar to those used to using installed apps.

Meanwhile, for Manhattan Mini Storage, the reservations and leads that are generated by the new mobile site are identical to the desktop experience, allowing them to communicate in the most efficient and customer friendly way.

Features

I don’t want to rehash all of Colin’s points but, quickly, let’s review a few:

WordPress, like almost every other content management systems (CMS), provides a set of administration tools from which users of varying permissions can write, edit, and publish content from.

This system allows for a hierarchal publication system that almost anyone who’s worked, or heard of, a newsroom might be familiar with. One WordPress site can have dozens of writers and a handful of editors checking the content before determining when it can be seen on the site itself. Obviously, on a site run by a single person writing and publishing, this model flattens, but it allows a lot of collaboration by many different people while ensuring that content is of a certain level.

That it also stores content in a display neutral way (ie. without the site’s design embedded) is also a major feature but one most people probably won’t take advantage of unless the site’s look and feel changes on a regular basis.

Other built in features that are useful for publishing is the ability to categorize and “tag” content with various “taxonomies”, each of which can be used to organize and display the content with other like articles. This becomes extremely important as the amount of content on the site grows and readers need a quick and easy way to find related material.

Lastly, WordPress (again, like many other systems) offers the ability to upload, display, and attach media to posts for display.

However…

While WordPress has evolved from a simple blogging platform into a full-featured, mature CMS, the complexity of the admin tools and plugins have grown as well. For even a relatively inexperienced web-developer, these tools are still simple to use, because web-developers are comfortable with reading the information on the screen and the concept that it all works the same way even if the names and labels of the fields may vary.

These two ideas, while obvious to those of us used to abstracting and templating, can be a major hurdle to a person with little to no developer experience who needs to administer their website. Even though the internet, in it’s current form, has been around for almost 20 years, a lot people don’t read what’s on the screen in front of them. This can be because of the way the information is presented or because there’s simply too much of it to digest easily. Pushing buttons and making “magical” changes can be daunting, because inexperienced administrators don’t want to mess things up and, more than likely, don’t understand what is actually happening when they push buttons.

Communication is the Key and Patience is a Virtue

42 Solutions has performed many custom WordPress installs for a range of clients, many with negligible internet experience and we’ve found a common thread with all of them:

1. Clients don’t know nearly as much as you do – I may be Master of the Obvious here but you’re the one being hired to perform a service they can’t do for themselves and it’s important to remember this when communicating how the CMS, or anything you built, functions. Don’t talk down to your clients, they’re not stupid (Once again, they hired you, so they can’t be dumb.), they just don’t have the same skill sets as you. Be patient with questions whether on the phone or emails. An easy way to avoid frustration is to prepare a cheat-sheet or customized, abbreviated manual that you can send to clients filled with FAQ’s and common functionalities.

2. Be prepared to answer a lot questions – Whether over the phone or email, you will probably need to answer a lot of questions that you think are obvious or ones already answered. But it may take more than once for the concept to be understood. Most worth learning do.

3. WordPress can do almost anything, but the client probably doesn’t know that. – Make sure to scope the project as accurately as possible and suggest existing plugins wherever possible. Connected to this is that it’s also important to communicate to the client that WordPress is a framework and that it generates pages “automagically” based on the the theme designed. Many clients get hung up on the number of pages of their site and how much “design” needs to be done, while in reality, because of theming, the bulk of time will be spent on loading the site with data. To avoid doing the data loading yourself, again, communicate clearly and effectively how the system works, so the client can add their own content. This cuts down on your work and allows them the time to learn the system.

Conclusion

The biggest problem with WordPress isn’t really WordPress. And it certainly isn’t the client. It’s usually with the consultant. The consultant assuming too much while not being patient enough. However, this is easily overcome with proper preparation, project planning, and building in the time to train the client on the system that’s been delivered. This is the surest way to ensure maximum client satisfaction and a consultant who hasn’t pulled out all his hair.

It really comes down to this: even Facebook’s competitors admit that Facebook is the leading social network out there right now. Sure, there are others that dominate in other markets, but, for 42 Solutions and the American and European market we are interested in, Facebook is the bee’s knees.

So, given that, why switch to Facebook comments? Because it provides the lowest barrier to entry for our readers.

Most of the people who find our website find it from the United States. And, given that the United States is almost dominated by Facebook users, providing a commenting system for them that uses their Facebook accounts just makes sense over them having to register anew for yet another website.

As we’ve learned working for our many clients, the lowest barrier to entry always has the highest number of results. And, since we also do social media, we feel as though we should put our money were our mouths are and adopt social media on our website to prove that this is where the most traffic comes from.

So, while the comments that were on blog posts before will now, unfortunately be gone, we hope they will multiply now that we’ve made the commenting system easier for those already logged in via Facebook.

As for those worried about losing SEO value because of the missing comments, our response is that the traffic gained from social comments is far higher than what might be lost due to comments made on the actual site. In a large part, this is because of the new discoverability of the content as a whole, now being potentially posted on the commenter’s Facebook feed, and the links that he or she’s friends might make back to our site even without adding a comment of their own rather than not participating or knowing about it at all.

It was a choice for us, no doubt, especially considering our excellently designed WordPress commenting system but one in which we ultimately feel confident.

Which is not to say that maintaining a commenting system does not have its merits. If you post content on a specific topic of little interest to the wider world, want to control who knows about what you’re posting, or perhaps want to restrict who can see and post comments, then maintaining your own comment system absolutely makes sense. However, those wishing to appeal to a wider audience, such as an online retailer or general interest website, might consider the benefits of social networking instead.

At 42 Solutions, we can help you determine which strategy is best for you. Contact us and we’ll help you figure out how best to reach your audience.

When the initial designs came down, I remember thinking to myself, “Well, hell, this will take all of a week to build.” Essentially, it involved a “dashboard” type design that could be manipulated and sorted a couple of different ways. Nothing all that complicated, really. Except for one requirement: we were to build it using Backbone.js.

For those who are unfamiliar with Backbone, it’s essentially an MVC library for JavaScript, to help modularize the code for single page HTML 5 dynamic websites. Even un-minified, it’s has a tiny footprint but a large effect on any project.

The Good

The upsides to using Backbone.js are many and, though I was loathe to originally support it, it has won over even me who usually objects to frameworks for framework sake.

Backbone offers a nice way to modularize front end code, including HTML layout and event handling. It is divided up into three main kind of “classes”: Models, Collections, and Views. (There are also “Routers” but for the purposes of this post, I’m going to leave them out for the time being.) Models represent a single data item to be displayed on a webpage. Collections represent a list of Models. And Views represent both the representation of an individual Model as well as the general layout.

On the current project, we define two different kinds of Views: Widgets and Views. There is no class or definition difference between them, merely a nomenclature of the individual files themselves. Generally, we define Widgets as being the representation of a Model and Views as a representation of a larger layout or Collection. This is helpful when looking for specific items. Does it affect the way items lay out in a list? It’s a Widget. Does it affect the larger layout? It’s a View. When naming things in this way, it helps keep the project organized.

Models and Collections generally represent the backend data object and there is little creativity in them. Where Backbone.js really shines is on the View layer.

Each View can separately bind events to itself and handle those events keeping project management limited and maintainable. If an event is firing (or not) when clicking on a specific item, it’s easy to know where to go to find where that is managed. Every item is specifically responsible for managing its layout as well.

Backbone also encourages the separation of layout and logic, a frequent issue with JavaScript who’s main job is to manipulate the DOM. Because of it’s dependence on the Underscore.js library, all the templating features included with Underscore are available in Backbone as well, allowing for discrete chunks of HTML to be created and manipulated through the normal use of jQuery.

This can’t be emphasized enough. With most projects using jQuery, and I am also guilty of this, the chains of chained callbacks becomes so long that the code is essentially unreadable after it’s done, a serious maintenance issue. As an example, see the not too exaggerated pseudo-code below:

$.ajax({
url: '/api/get_profile.php?id='+id,
dataType: 'json',
success: function(data) {
//do something here. Maybe a call to another function.
doSomething(data);
},
statusCode: {
404: function() {
//handle not found...
},
500: function() {
//handle server errors...
}
}).done(function(data) {
//handle post-op whatever
});

The chain, as you can see, quickly becomes unmanageable and, even worse for any company that wishes to ever change its business model, unmaintainable. Backbone solves this with its simple and object oriented construction.

Additionally, if the REST services that the frontend queries are built to Backbone’s standard (utilizing GET, POST, PUT, and DELETE HTTP methods), then most CRUD operations are handled transparently. This is a massive advantage as the data handling code is already written and can happen with little work on the developer’s part. This alone makes Backbone.js a library worth investigating for use in any frontend project. But it does come with a few downsides…

The Bad

Like any framework, Backbone.js requires that developers need to learn the way that it does things. This can be good in the case of DOM manipulation and event delegation or potentially bad in the case of the REST service calls mentioned above.

As an example of the potential for bad, consider a REST service where there is one method for getting data and another for saving. It can be as simple as:


GET /api/get_profile.php?id=10

POST /api/save_profile.php

Logical, yes? Chances are, many of the services you are fetching or saving to are built like this. But Backbone.js is built with a mind toward REST “standards”. So that all services should be essentially the same URL with the HTTP method being used to determine how the service should react. An example:


GET /api/profile/10

PUT /api/profile

POST /api/profile

DELETE /api/profile/10

GET always fetches the data, PUT and POST will save or update depending on the standard though Backbone always uses PUT to update and POST to save, while DELETE is supposed to remove the data.

How many services does anyone know that are built this way?

At our client, where the services are being built from scratch, this is doable. But when dealing legacy services built to the first example, each model essentially requires an override of the basics of how Backbone processes service calls. And while this can be nicely encapsulated into each Model, it still adds development overhead for not having built the backend for the way this library thinks you should have.

Which leads to perhaps the biggest downside of Backbone.js: It’s yet another framework developers must learn.

I once read an article that said the biggest challenge to developers was not the language, those were easy enough to pick up, but frameworks, that use a known language but add their own learning curve to effectively implement. This was years ago and it was specifically referring to jQuery but the theme holds. A developer may know PHP but do they know WordPress? You may know Java but do you know Spring?

It’s not enough to just know JavaScript to implement Backbone. One also has to know the way Backbone does things. And in this regard, the documentation is sorely lacking. Writing a frontend application in jQuery may be a mess of chained function calls that are ultimately unmaintainable but it can happen quickly with an immediate result. Backbone adds a layer of complexity, requiring that the backend data model be entirely reproduced on the frontend and then have individual views created to represent every object.

Rather than having something to show in hours, Backbone requires days. Not unlike a Java versus a PHP project.

The Verdict

It’s a tough call to determine whether the overhead that the Backbone.js library imposes is worth it. There are many pluses and minuses to take into account. Thus, the verdict is bound to be mixed. So here it is:

If you are running a large web project with multiple developers, a long timeline, and the resources to absorb the startup overhead and learning curve, then Backbone is the right tool to use. Its encapsulation features alone make any project using it far more maintainable in the long term than writing straight up jQuery.

However, if the project that its being considered for is small, without a fair number of developers, or will be rewritten in two months when the business model changes yet again, the overhead of Backbone just isn’t worth it. It is not a rapid development platform and the maintainability it brings to a project is not worth it if everything will be scrapped tomorrow.

Still, Backbone is a step in the right direction, a lean library that imposes some standards on developers while offering simplicity in many areas of common frustration. It’s biggest disadvantage is that of many frameworks, in that it was built with what the developer believes to be best practices, the real world be damned. What it imposes may in fact be best practices but rarely do those ever make it to the final product where delivery date trumps ideal every time.

First of all let me start by saying that browser testing for IE is one part of my job that I hate the most. THE. MOST. I wish IE7 and, to a lesser extent, IE8 would die quick deaths, but, no. That would be too easy, as I’m sure you remember how long it took for IE6 to go the way of the dodo.

Fortunately, most IE8 issues can be solved with the simple meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=Edge" />

But IE7 has it’s own problems, especially when dealing with absolutely positioned elements. Take the following piece of CSS that positions the diagonally slanted stripes on the top of the 42 Solutions website:

.topDiagonal {
background-color:#bf7300;
background-image: url("../images/TopStripeDiagonal.jpg");
background-position: right bottom;
background-repeat: no-repeat;
height: 353px;
width: 50px;
margin-left:1020px;
position:absolute;
}

This CSS places the stripes perfectly in FireFox, Chrome, Safari, IE8, and IE9. Essentially all the real browsers. But in IE7 the margin-left attribute creates a block that pushed down all the surrounding elements like so:

Messed up, right?

Given that we’d just launched the new site, I figured we had two options:

1. We could throw in some javascript and a splash window to display a message for IE7 users along the lines of, “*sigh* Really? Won’t you please upgrade you obsolete and increasing ancient browser?” But unfortunately many of our corporate clients still use it and it would’ve undercut the fact that 42 Solutions offers browser QA testing as part of our services. So,

2. I guess I just had to bite the bullet and fix it.

There are a few tricks to fixing the IE7 float problem, but my favorite is to use a conditional stylesheet in combination with simple CSS changes for IE7. By viewing the source of the 42 site, in the <head> section, you’ll see:

<link href="http://www.fortytwosolutions.com/wp-content/themes/fortytwo/css/42main.css" rel="stylesheet"
type="text/css" />

<!--[if IE 7]>
<link href="http://www.fortytwosolutions.com/wp-content/themes/fortytwo/css/42main7.css" rel="stylesheet"
type="text/css" />
<![endif]-->

The first line is a link to the 42main.css stylesheet that contains all the CSS rules for FireFox, Chrome, Safari, IE7, IE8 and IE9. After that follows an if statement that tells the site if the browser being used is IE7 to then use 42main7.css. Since the styles cascade down (The 'C' in CSS), I only have to include the modified rules that only applies to IE7 in the alternate stylesheet.

The rule .topDiagonal in the IE7 stylesheet is defined as

.topDiagonal {
background-color:#bf7300;
background-image: url("../images/TopStripeDiagonal.jpg");
background-position: right bottom;
background-repeat: no-repeat;
height: 353px;
width: 50px;
margin-left:1020px;
position:relative;
margin-top:-346px;
}

The main difference here is that I used relative positioning instead of absolute. Using relative positioning and then figuring out the difference with a negative top margin has always been one of the easiest fixes for correcting the IE7 absolute positioning bug. And, since the IE7 stylesheet contains only the modified rules, I don't have to maintain two full stylesheets. I can design and code for the majority of the browsers out there and then just modify the specific rule causing the problems in the alternate stylesheet.

Cross-browser compatibility is going to be an issue until the older non-compliant die but, until then, I guess we'll just keep hacking the bugs.

“We’ve been building a series of sites using WordPress,” said Partner Colin Andrew Ferm. “And it’s worked for our customers who have had much more demanding needs than we do.”

The process began when the partners of 42 Solutions looked at the website and the glaring lack of content on it despite the large amounts of work the company has done. Deciding that it was finally time to build a presence on the web that accurately represented the firm, they decided that true content management was necessary.

“That we were still tossing up flat pages when we wanted to say something was ridiculous,” said Partner Dan Kellner. “And it stopped us from communicating to potential clients who we were.”

“It was a case of the cobbler’s children having the worst shoes,” Ferm said. “We’ve been so busy working on client websites we’d neglected our own.”

In less than a week, the existing design of the old flat 42 Solutions website was integrated into the WordPress framework, allowing the new site to instantly benefit from many of WordPress’ built in features. These include content tagging for related items, categorization, separation of content from design, and comments.

“The hardest part was not actually building it,” Kellner said. “But adding the actual content for it to display.”

So now that the 42 Solutions site has been re-launched, what comes next?

“Like anyone who runs a content site, it’s our responsibility to keep things fresh,” Ferm said.

As with every site 42 Solutions has built, the new one continued to contribute to the library of software tools the firm has build for use on future client websites, lowering the overall time for implementation and, therefore, the cost. And while many disparage WordPress as merely a blogger’s tool, the 42 Solutions design proves that not all WordPress sites must look or act alike.

“The toughest thing is finding the upfront time or money to implement a tool like this,” says Kellner. “But when taken over the long term, it always has a net savings.”

42 Solutions understands the needs of site owners to keep their development and maintenance costs down. How can we help you do the same?

Approached in late 2002 to allow Manhattan Mini Storage customers to make reservations for storage rooms online, 42 Solutions was presented with a three page specification of the few features they wanted to see. Partners Dan Kellner and Colin Andrew Ferm spent the next several weeks and months flushing out the requirements until finally discovering that the reservation process was just one aspect of what the proposed site was supposed to do.

In the end, Manhattan Mini Storage naturally wanted a fully featured website for their customers, one that would not just allow them to make room reservations but one that would also allow them to purchase packing supplies, manage their accounts, and pay their bills online. In short, it wasn’t going to be a small project and, nine years later, it still isn’t.

The Initial Release

Rather than moving forward in a phased approach, Manhattan Mini Storage wanted the entire site with all its features to go live at one time. This meant building out each feature, testing and validating it before moving on to the next so that Manhattan Mini Storage could see the progress on the new integration server.

Perhaps the biggest challenge was working with the existing reservation system that powered not just the reservation call center but also each storage location and managed the entire company’s inventory. 42 Solutions solved this problem by using the database that powered the new website to act as a “middleman” between the old system and the new, pulling inventory and customer data from the existing system for use on the web while pushing reservation and payment information back.

Using the Java/J2EE architecture to ensure high availability and componentization development was rapid and by March of 2003, the new Manhattan Mini Storage website was ready for deployment. 42 Solutions advised Manhattan Mini Storage on both the server hardware purchase as well as the colocation provider and set up the system to host the website. Once all the pieces were in place, the site went live and was more successful than anyone could have imagined.

By the end of the first month alone, the business being generated by the web was equal to one of Manhattan Mini Storage’s seventeen locations and bill payments made on the web reduced overall costs marking an additional benefit to Manhattan Mini Storage’s entry into e-commerce.

Refinements

With the initial release a success by any measure, the managers of Manhattan Mini Storage began dreaming up new ways to generate business from the website. New features were added on a regular basis including the generation and mailing of “e-bills”, statements emailed to their customers with direct links back to the website to make payments. Those who subscribed to e-bills also had the ability to remove themselves from receiving paper bills, saving Manhattan Mini Storage hundreds of dollars a month just in billing costs.

And, while the website launched with the ability to pay by credit card, the cost of transactions completed with checking accounts was much lower. So the website was soon integrated with a second payment processor, giving Mini Storage customers the option to pay with a new method in return for a small reduction to their monthly bill.

Version 2.0

42 Solutions, as the original developer for the Manhattan Mini Storage website as well as the other websites for the parent company Edison Properties, was invited back when Manhattan Mini Storage felt their groundbreaking website was due for a refresh in 2008. A lot had changed on the web in those five years and 42 Solutions brought many of those innovations to Manhattan Mini Storage.

Beyond updating the look and feel of the website and sliming down the reservation process, 42 Solutions rewrote the entire front end to take advantage of the features in modern browsers. Google Maps replaced old image maps of where Manhattan Mini Storage was located, allowing customer to zoom in and out. Geolocation was used to help provide customers with the closest location to where they lived. And the power of HTML and CSS combined with the powerful new jQuery JavaScript library allowed 42 Solutions to create a new level of interactivity for Manhattan Mini Storage’s customer.

And while the Java architecture of the site remained solid and stable, many of the underlying technologies were stripped away and replaced with the latest open source libraries to ensure forward compatibility and to leverage the work of thousands of developers.

Naturally, this refresh of the website became known as “Version 2.0″ because of the breadth and depth of the changes being made. But, in the end, Manhattan Mini Storage ended up with a website that would work for several more years without a major revision because of this one time update.

Version 3.0

Once again, in 2011, Manhattan Mini Storage decided that their website, still the leader in the space, required an update and turned again to 42 Solutions, by now Edison Properties’ longest serving web partner. Working from a design by ReadySetRocket, 42 Solutions revamped the entire reservation process to create perhaps the easiest workflow yet for customers in search of storage space.

Again, the look and feel was modified to integrate with the clean new interface and the entire site experience a facelift while the underlying technology remained almost entirely unchanged.

Taking advantage of AJAX technology, 42 Solutions also created a series of RESTful interfaces that could be called by pages on the website to generate content on the fly, a feature that came in handy again when Manhattan Mini Storage realized that the future was increasingly mobile.

The Future With Mobile

In late 2011, 42 Solutions again worked from a design by ReadySetRocket to create a mobile version of the reservation process. Built entirely using the new HTML5 standard, the mobile Manhattan Mini Storage looks and acts like a native mobile app using nothing more than HTML, CSS, and JavaScript. Now, customers using iPhone or Android devices can make reservations for storage rooms in the smallest and simplest workflow yet, designed specifically to work with handheld devices.

Even in the world of mini storage, business is always changing and, as a partner with Edison Properties and Manhattan Mini Storage, 42 Solutions remains ready and able to adapt their web presence to new realities and customer expectations.

After succeeding with the Manhattan Mini Storage website, parent company Edison Properties turned once again to 42 Solutions to bring its Edison ParkFast brand into the 21st century.

Wanting a site that accurately reflected it’s ParkFast brand while including dynamic functionality to display location rates, hours, and facility information, Edison ParkFast was not looking for a site nearly as complex as the Manhattan Mini Storage presence but neither could it be a “brochureware” site either.

In early 2004, 42 Solutions presented a design that we felt reflected the brand and the urban locations it serves in New York City, New Jersey, and Baltimore with the flexibility to include time sensitive information and offers while still getting the customer to the information they were looking for as quickly as possible.

After a few short iterations of design changes, approval was granted and 42 Solutions set about making the site come to life. Utilizing the same Java/J2EE architecture that made Manhattan Mini Storage a success and reusing several of the same components, 42 Solutions saved development time and costs building ParkFast’s new presence.

Like Manhattan Mini Storage, the Edison ParkFast data was stored centrally on an legacy sever. To bring that data to the web, 42 Solutions again used the database engine to act as a “middleman”, fetching data from the server for display and returning customer requests as they were made.

A series of administrative tools were also built, allowing ParkFast employees to denote specific information about locations that only needed to be applied on the web. With this, Edison ParkFast could then highlight locations offering special services like electric refueling and scooter parking to interested customers.

A New Idea

Taking a page out of Manhattan Mini Storage’s book, Edison ParkFast decided that it wanted to experiment with allowing customers to reserve their parking option ahead of time. With locations near the new Prudential Center in Newark, NJ, ParkFast believed this would be especially useful for concerts and sporting events hosted there.

42 Solutions jumped at the task and created a simple three step reservation process wherein the customer picked the event they would like to see parking options for, pick the parking option that was best for them, and reserve with a minimum amount of information and no money down. In return for making a reservation, ParkFast customers were rewarded with special event pricing.

The result was better than anyone could have imagined.

Within days, hundreds of reservations had been made, allowing ParkFast to gauge and distribute demand across its multiple locations. Customers, too, loved the security of arriving on the day of an event and knowing they wouldn’t be turned away. It was win-win for everyone but especially for ParkFast who prides themselves on customer service.

In the weeks that followed, Edison ParkFast used the new tool created by 42 Solutions to offer reserved parking at events in Manhattan and, when it opened, at its lot near the Secaucus Junction Station for customers of New Jersey Transit commuting to and from New York City.

Continued Support

Just because a website has been built, launched, and used by thousands everyday doesn’t mean the work is over. And 42 Solutions is not the type of consultancy to abandon a client in need. Though little actual development work is required, like any business the business of providing parking changes sometimes from day to day.

42 Solutions maintains a close relationship with the Edison ParkFast brand, updating the site’s look and feel, content, and business rules to adapt to the changing ways ParkFast communicates with its customers. 42 Solutions remains there for its customers, providing years of service.

Renowned in the field of conserving and restoring works on paper, JD Conservation approached 42 Solutions to redesign their existing website. Art Conservator Jon P. Derow was no longer happy with the current look and feel of the site and communicated that while clients were always happy with the reults of his work, the website did not accurately portray those results to potential new clients searching for an art conservator. He wanted the before and after images of works he had restored to be the focal point of the new design so pontential clients could immediately see the quality of his restoration process.

The Process

After 42 Solutions met with Mr. Derow to to get his input on general asthetics and required elements, 42 Solutions did research on JD Conservation’s competitors to analyze the strengths and weeknesses of their sites.

Combining what he learned about the sites that already existed in the art conservation space and taking into account Mr. Derow’s mandate that the work be the focus, 42 Solutions researched dynamic muiltple photo gallery that could best be used to display the before and after versions of the restored works and created multiple initial homepage designs.

42 Solutions then met with Mr. Derow to discuss the various designs and galleries to ascertain which elements he preferred. This meeting began the iterative feedback and design process that allowed 42 Solutions to quickly complete the homepage and gallery layouts.

With the homepage and gallery design complete, 42 Solutions began constructing the site and filling out the rest of the content based on a style-guide derived from the homepage, periodically showing Mr. Derow progress so he could makes comments and changes.

Since the original site was built on a now obsolete mark-up structure, 42 Solutions modernizd the site site structure to make the site easier to update, obtain better search engine results placement (SERP), and integrated Google Analytics with the Google Adwords account Mr. Derow had already been using.

The Result

Mr. Derow was extremely pleased with the outcome of the site and the increased business generated by its new search engine visibilty, saying, “Working with 42 Solutions was a breeze. They understood immediately what I was hoping to achieve and presented a variety of excellent solutions from which I could choose. Most importantly, Partner and Designer Dan Kellner had no ego invested in the design choices; though he voiced his preferences and explained his reasoning, he never pressured me to use a preferred design. I am thrilled with the understated, professional site 42 Solutions created, and they have been quick to implement any minor changes I’ve requested.”

A “storyworld” is more than just the background of a story. It’s the rules by which stories must operate, determining whether certain things exist at all and governing when certain things are available. A story set in the real world wouldn’t have a ’69 Malibu in the year 1955. Neither would a Rayo Stallion exist in the Unified Republic of Stars in 2178. And because it’s science-fiction, there are no wizards, trolls, or dragons.

Beyond that, a storyworld offers a timeline of events that have happened or will happen, allowing a storyteller to weave their stories into a larger timeline. In this way, a story might act as a prelude to a major military action or be set on a backwater moon, oblivious to the battle happening in space above them.

Of course, in almost every way a storyworld is as much a story as the individual stories themselves.

Colin took this to heart and, over the course of seven years, kept building the world until it was comprised of two 50,000 word history books and a spreadsheet of facts and figures pushing ten megabytes. And, after having written one novel and a dozen short stories set in the world, the obvious question became, what now?

Enter partner Mark Harris, also a storyteller and filmmaker. Seeing the sheer size and scope of what became known as The Unified Republic of Stars, Mark suggested  publishing it onto the internet for others to use and build on.

But how?

Fortunately for Colin, the state of open source web collaboration tools has reached a state of maturity and it soon became a process of selecting the tools not just with the most power but also the easiest to build upon. In the end, he selected WordPress to handle to story publishing element and MediaWiki to act as the storyworld’s encyclopedia.

Each system was uniquely suited to their given tasks, WordPress because it has become the leading publishing tool on the web and MediaWiki because it is the software the powers the Wikipedia. By combining the two with a series of extensions to the core software, Colin was able to create not just a Unified Republic of Stars but also a unified user experience, allowing readers to jump from stories to reference material and find which stories reference particular elements of the world.

Licensing the content under a Creative Commons Attribution, Non-Commercial, Share Alike license, storytellers and creators may build upon the original storyworld so long as their creations are not sold and original attribution is given. And though Colin retains editorial control on the stories published, the reference section is wide open for those who wish to collaborate by editing or adding articles on subjects that interest them, from the accomplishments of a future baseball league, to the many types of ships that fly through space, to the economics that drive human interaction.

With three hundred content articles, a followed blog on space and story developments, and a dozen stories that take place in this possible future world, the Unified Republic of Stars is a testament to the power of collaborative storytelling.

And with the technology developed to blend the power of two of the web’s most popular content tools, 42 Solutions has the unique ability to bring the features of the Unified Republic of Stars to any story and world told on the internet.