When I made the decision a few weeks ago to purchase a tablet I started to do some preliminary research.  To that point in time, I really hadn’t investigated what was available. Sure, I’d heard about the e-reading manufacturers branching out in to the mobile browsing market, but I wasn’t quite sure to what extent.

What I found I really surprised me. There were no fewer than 12 seemingly good options from a hardware standpoint that were available.  This got me to thinking about how we, as the web and software development industry, will deal with the explosion of available devices that should be accounted for from both a technical and strategic standpoint.

Do we test against Amazon’s Kindle Fire Browser? If so, how do we account for the upgrade that will be released mid-way through a project? I would think that they’ll be enough browser versions, hardware types, and screen sizes to make all of our heads spin.

I’m not sure that the businesses we serve have fully adapted to the explosion in HTML browser compatible smart phones yet. Now they need to be budgeting for design and testing considerations for screens ranging in size from 3 to over 10 inches in size as well? What a challenge awaits our industry, along with the marketing industry, as we go through these changes!

For the time being, I suppose that we’ll all do our best to identify key systems and audiences like we always have, we’ll just have to broaden our view of what the possible answers could be. It probably won’t be so simple as to account for iPhone, Blackberry, and Android devices any longer. You’d have to expect that budgets will be raised to account for these key users and their respective platforms. 2012 is going to be an interesting year for our industry and I am excited to see how these changes affect the way in which we approach our work.

And…for the record, I did end up going with the Samsung Galaxy Tab 10.1. I’ve had good luck with the Android platform to date, although the app selection does seem to be a little less well-developed than the iPad offerings, but I’ll save that for another post on another day.

Merry Christmas Everyone and happy Tablet-ing!

It is acceptable to say that the mobile web is here to stay. Mobile devices, such as smartphones, tablets, and netbooks, presently have a massive user base. The number of mobile web users is expected to steadily increase as more and more users turn to their mobile devices to instantly access information. In fact, according to Morgan Stanley, the number of users browsing via mobile devices will exceed the number of users browsing via desktop computers by 2015.

In the face of this massive change in browsing proclivities, many companies are unsure how best to tap this growing market. As my colleague pointed out last week, even major web applications like Salesforce are not fully compatible with the majority of mobile devices. Other major sites have tried to simply slap mobile-specific versions of their sites together, which has led to user frustration that consequently shows up in comics like the one below. So, what is the best path to capturing all those mobile users? The answer is (as it usually is) complicated. However, there are several common approaches, including mobile-friendly sites, custom mobile sites, and native apps, that most sites would be well-served to adopt.

Server Attention Span courtesy of kxcd

Common Approaches

There are three major approaches to dealing with mobile devices. Each approach has unique virtues and challenges, and some sites may lend themselves to one approach more directly than another.

Mobile-Friendly Site

Usually the most cost-effective approach, a mobile-friendly site relies on the massive increases in power and usability that have swept through the mobile market in the last few years. The fact that Apple’s iOS, Google’s Android, and Microsoft’s Windows Phone 7 all include desktop-class web browsers by default means that many sites will simply work “as-is” (or with only minor revisions) on most modern mobile devices. Of course, making the site mobile-friendly usually limits the types of technology that can be used (Adobe’s Flash being the most affected). However, many relatively simple sites can be made perfectly usable on a mobile device with minimum of time and effort. It should be noted that the number one limiting factor for this approach is that it can be very difficult to design a site that is both usable and attractive on both a 27-inch desktop monitor and a 3.5-inch phone display. In addition, data-heavy applications may be too complex to make this approach viable.

Custom Mobile Site

This approach creates a custom site dedicated to creating a distinct user experience for mobile devices. When a mobile browser is detected, the user is redirected to the custom site. As shown by the comic above, some thought needs to be put into this redirect to prevent user frustration. However, this can be a good middle-ground from a cost and market-coverage point of view. The custom site is more expensive to develop than just making the existing site mobile-friendly, but the fact that it is still an HTML-based site in a browser avoids many of the pitfalls of the native app. The downsides are that HTML-based solutions will never be as responsive as native apps, and truly complex web applications may still cause a frustrating user experience.

Native App

This approach is almost always the most expensive, but often yields the most user-friendly results. A native application will most likely be the most responsive to inputs and it will give the designer more leeway in presenting complex datasets or controls to the user. In addition, the developer can leverage the standard APIs for each platform to provide a standardized experience that functions exactly as the user expects, so there is a minimal learning curve. The downsides to a native app can be fairly serious, though, as it will most likely be the most expensive and/or time-consuming option to create. Likewise, distribution to the end user is much more difficult and someone will have to provide ongoing support, bug fixes, etc. in the same manner as a desktop application. Finally, the biggest issue will be determining which platform(s) to support since each platform uses different tools to write native apps. In other words, to support the “big three” mobile OSs, it will require three separate apps built from three separate code bases.

Choosing the Best Approach: Define Your Audience and Check Your Content

As with any decision that revolves around web applications, your target audience should be your first consideration when trying to choose an approach. If your site targets a demographic that is likely to own a particular brand or type of mobile device, it can make your choice easier. However, your decision also must take into account the types of data and services that are available via your site. If, for example, your site is primarily used by engineers during their workday to calculate airflow requirements for HVAC systems, spending time and money on custom mobile sites is probably not a good use of resources. On the other hand, users can often surprise you with the strange uses they can put a site to once given convenient access in the field.

There are obvious differences between the mobile version and standard version of the Domino’s website. Mobile web users will likely take to the mobile version.

On the other end of the mobile-usefulness spectrum, I am astounded at the number of restaurant websites that are completely inaccessible on a mobile device. These sites have a target audience that is highly likely to want to visit their site while using a mobile device, but they don’t take even the most basic steps to allow mobile access. This is a mistake that will make less and less sense as more and more of the world moves to mobile web access.

One final thing to keep in mind when choosing the best approach is that even if your application’s current content is not conducive to access via a mobile device, it may be possible to make the site mobile-friendly by re-designing the interface without actually changing any of the available data. In fact, one of the greatest side effects of making your site more mobile-friendly is that it may become more user-friendly in the process, regardless of device!

Your Mobile Visitors Will Thank You

The future of the web demands that sites are built to be easily accessible, functionally fit, and user-friendly on mobile devices. Users not only want to be able to access information instantly on their mobile devices, but they want to be relieved of the frustration that is tied to poorly developed mobile sites. If your target audience fits into the increasing number of mobile web users, now is the time to consider adopting an approach that best suits their needs. Whether this approach results in a mobile-friendly site, a custom mobile site, or a native app, a mobile version of your site will help to make the web a more compatible environment. This will not only alleviate the pressure to adapt to web mobility in the future, but it will give your mobile visitors another reason to stay.

So obviously there are plenty of people that still need to know why they need one. Below are some of the most common reasons that businesses do not have websites and why those reasons don’t hold up under further scrutiny.

1. My business doesn’t need a website.

Nothing could be further from the truth. I’m not saying that there aren’t some exceptions to the rule, but I can hardly think of a single type of business that wouldn’t, in some way, benefit from having an online presence. According to InternetWorldStats.com, in North America alone, there are about 270 million internet users. That’s roughly 80% of the population. And if your customers are global, that’s only 13% of the world’s internet users. Let those numbers sink in for bit. To choose to not advertise to that many people is unthinkable.

Even if your company doesn’t exactly sell something online or provide a service that uses the web, you’d be surprised still at how many people will seek information about you from the internet first, before any other means.

2. It’s too expensive.

I have two thoughts on this one; the first one being is that it isn’t as expensive as you think. It really depends on what you want your website to do. A static, brochure type of website will cost a lot less than having your own Facebook. Its important to first find out what your needs are as far as an online presence. If you find that you need a large and complicated site, odds are that this article doesn’t concern you anyway because you already know that you need a website. Static brochure websites aren’t expensive at all compared to other forms of marketing. With the right planning and forethought, the entire process can be streamlined into a very inexpensive and cost effective project.

My other thought on this is that, while the goal is to not spend too much on a website, you also don’t want to spend too little. Sure, your teenage nephew might be able to make a website, but I’d be highly dubious of how professional and effective that website would be when it’s completed. A website is your online business card. To many customers, it will be their first impression. You don’t want that impression to be that you are unprofessional and unwilling to put effort into your own website.

3. It takes too much time.

On the contrary, having a website can actually save you a great deal of time. The time involvement is front loaded. It may require extra time while creating the site, but once it’s done, it’s done. Adding additional content is, in most cases, relatively quick and easy. And again, the time a website will save you in the end in invaluable.

For instance, simply making a well thought out Frequently Asked Questions (FAQ) section to your website can not only save you time from having to repeatedly answer the same questions and concerns, but it will also save your customers time as well. Putting some photographs of the product or service on your site will ease customer concerns and keep you from having to explain things that can be said with images.

That is just one example that will open up large amounts of time for your business. I could probably write an entire post of the time-saving benefits of a website, but I’m sure you get the idea.

4. It’s too complicated.

If you are trying to create a website yourself and you don’t know a thing about web technology, then yes, it will most certainly be complicated. However, if you are having a website created for you, then no, it’s not complicated at all. As I said in the previous section, once your website is done, it’s done. Adding and updating content is relatively easy at that point, especially if you have a good Content Management System (CMS) to make things even simpler for you.

Once again, giving the proper forethought on what you want your website to do will be what you spend most of your time thinking about. The process of making your website live can be handled by most web development companies. This makes the process of having an online presence much less complicated and painful than many people think.

So as you can see, there aren’t many compelling reasons to not have a website for your business in today’s world. By not having one you are missing out on, literally, millions of potential customers. You are opting out of one of the most cost effective forms of marketing. You are more than likely using up your valuable time doing tasks that your website could be doing for you. And you are not utilizing one very simple and powerful tool to promote your company, vision, and ideas.

Every project manager knows that with any project that falls outside his or her comfort zone, it induces a level of unavoidable risk. Some project managers thrive on this risk and are able to haphazardly proceed with flying colors. On the other hand, some project managers buckle under the pressure and are not able to deliver a sound solution to the client. There are some project managers, however, who are able to navigate through this risk and achieve a balance that allows them to understand, accept, and manage this risk.

As the senior project manager at Galvin, I identify with the latter pool of project managers. I do not mind the risk that comes with uncharted territory; it keeps me on my toes and pushes me to think critically and creatively in bigger and better ways. However, it is important for me to understand what it is exactly it is I am getting into before any decisions are made.

The Challenge

Most recently, I ran up against this unfortunate predicament: our client needed a solution in which the time and budget did not allow for us to be able to utilize the best of our internal resources to develop a fully-customized software solution. Thus began my challenge to discover how to deliver an end result that would be able to exceed the client’s expectations while being considerate of a strict timeline and budget. To ensure that I am leading the client down the right path, I rely on the following four tips, which have proven to be useful in such challenging situations.

Stay Positive and Confident

When faced with a project that forces you out of your comfort zone, it is especially important to remember to stay positive. The fear that stems from the unknown, especially in projects where it is hard to visualize the end result, is understandable. It is also natural to feel anxious in these fearful situations, but a project manager must be able to push all of this aside. Instead of catering to fear, the project manager needs to actively maintain a positive attitude that instills confidence in all the project stakeholders. If you believe it can be done, it will be done. Sometimes it is a matter of simply saying, “Yes, we will deliver the right solution.” Say it a few times and suddenly, the project seems easier to tackle.

Realign Client Expectations

Your first interaction with the client after the project has been signed off is absolutely critical. I always take this moment to realign the client’s expectations, especially in cases such as this where the risk is high, the budget is tight, and the schedule is strict. Although the client is dead-set on a certain solution, sometimes there are requirements that were not initially identified that need to be discussed. Likewise, sometimes there are requirements that need to be carefully reviewed to ensure that each one can be properly met. If I am up against requirements that just will not work, then this is the time in which I employ the art of compromise. From my experiences as a project manager, I believe that compromise is necessary in order to swim outside the box to find the buried treasure. Not only does it show the client that you understand what it is they need, but it also enforces the message that they are in good hands.

Research, Research, Research

A project of high-risk cannot be delivered successfully without doing a fair amount of research and development. To find a solution that would fit within the restricted budget and timeline, I needed to look beyond our internal resources and to third-party sources. Based on the client’s expectations and project requirements, I researched viable options and then was able to created informative documentation to present to the client. Not only did the presentation generate valuable feedback, but it allowed me to narrow my selection of 5 to 6 solutions down to 3 and 4. Although it does feel encouraging knowing that we are on track to finding “the one”, there is still that nagging feeling that I need to make the best decision, the one that will give the client a bigger bang for their buck. However, I remain positive that our understanding of the project’s requirements will allow us to make the most educated decision that will deliver a solution that generously exceeds the client’s expectations.

Keep Your Salesman Close

Last but not least, I make sure to keep my salesman – the one who approached the client with a solution in mind– as close as I can. As a project manager, it is important to do so for several reasons. If you cannot realign the expectations with the client during your first interaction, then it is time to call on your salesman to redefine the client’s expectations and project’s requirements. Likewise, if the solutions you have presented are not what the client wanted or expected, then it is necessary to call on that relationship between Sales and The Client to determine how to proceed. I trust that this relationship will encourage the client to compromise and accept a solution that I know will not only meet their needs, but I know that we can (and will) deliver.

The Next Step

Now that the client has narrowed the solutions down to 3 and 4, I am preparing to present a more detailed overview of these options to show how each one satisfies the project’s requirements. Because of the timeline and budget, soon I will need to go ahead and pull the trigger. In other words, I will need to make an informed decision to proceed with a third-party solution so we can begin the development process. Even though making this decision has proven difficult, I know that the worst is still not over; there is a timeline and budget that my team and I will need to be deeply considerate of until the very end.

Despite the fact that this particular project fell outside my comfort zone as a project manager, I welcomed the opportunity to learn and think more critically and creatively during the discovery process. Likewise, I appreciate the experience of this challenge, which I know will serve as valuable knowledge when similar projects fall under the umbrella of my management in the future. I have the utmost confidence that I am leading the client down the right path and that we will deliver the right solution on time and within budget, as promised.

Stayed tuned for Part II: The Challenges of the Development Process and Managing a Remote Team, in which Crissy discusses how “the one” solution was finally selected, how the team proceeded into the development phase, and how she handled the challenges of managing the project and its external resources, tight budget, and strict schedule.

Businesses love buzzwords. Many businesses will change their entire direction, sometimes against their better judgment, in an effort to attain the competitive edge the new “term” will give them. As quickly as trends come and go on the Internet, there simply is not enough time to research these new ideas thoroughly before implementing them. This leaves businesses not necessarily using the best practice or fully utilizing new concepts as they come down the pipes.

SEO (Search Engine Optimization) is one of these terms that has been spreading like wild fire. To compound the issues mentioned above, SEO is dictated by constantly evolving algorithms that are kept under lock and key by Search Engine companies.

Most people believe that the goal of SEO is to be “number one on Google.” This dogmatic mantra resonates through marketing meetings with cult like fervor. So much so that businesses are at times, losing site of the big picture.

The big picture is: the goal of your business. If your goal is to be number one on Google, then by all means, chant the mantra and go for it. However, most businesses are either offering a service or selling a product. With that in mind, while you are optimizing your site for search engines, make sure you are optimizing your site for customers.

It doesn’t do any good if you have a high rank on Google, but your website drives customers away in droves. Focus just as much on your site’s usability as well as its “findability.” SEO should be just one more tool in your marketing box, getting the same amount of attention as all of the others. An increase in traffic doesn’t equate to an increase in business. It simply increases the OPPORTUNITY to increase business.

While SEO is used in the context of being a magic bullet, know that it isn’t and use it for what it is originally intended and nothing more; and that’s simply making it easier for customers to find your site. The operative word here is “easier.” Not “the only” or the “best;” just easier. SEO, when working with other marketing initiatives will produce great results, but think of your marketing like a race car. When all the parts are functioning properly, the car will be able to stay competitive on the track. But regardless of how much work you put into the engine, your car won’t be going anywhere with flat tires.

Handing that baton off while running full speed is really a lot harder than you’d think it be. Despite how quickly it actually happens in real time, those teams have practiced it many times. The actual handoff occurs with a certain foot forward and a precise amount of time after the recipient of the baton has started moving. Most importantly, dropping the baton means losing the race!

Prior to any actual contractual agreements actually being in place for a project, it’s very likely that you’ve had several, if not many more, planning meetings with a sales-type person and probably even a pre-sales engineer. Think of this as the first lap of the race and playing the role of the baton are the project charter, initial project requirements, timelines, scopes of work, and situation specific details that could immediately affect the project.

In order for actual project, or second phase of the race, to get off on the right foot, it’s crucial that there be a clean handoff of this knowledge, or baton, to the members of the project team. How do you do this successfully? Just like a world class track and field relay team, it takes practice and an understanding of this fast, yet complex, interaction.

For our Galvin team, this occurs during the Project Kickoff meeting. If posssible, we prefer to have all key project stakeholders present. From the Galvin side, the personnel who are present are largely representative of the project scope itself. If its a database heavy application, we include our lead architect. Likewise, if we know that graphic or interactive design is a key component, we’ll include an interactive designer.

Once we’re able to get together there is a specific agenda that the meeting follows. This typically goes something like this:

1) Introduction to Roles and Responsbilities – We want to verify everyone’s role and responsbility in the project. Is there a 3rd party IT Manager who will be making DNS changes? Let’s identify and record that as a part of project foundation. Highlighting it early will avoid miscommunication later. Once again, no dropping the baton!

2) Highlight Project Objectives - This is where we’ll review the project scope of work and the Project Charter. This equates to not only what we’re setting out to do or how we’re going to, but to WHY the project has been authorized. In general, human beings work more efficiently when they understand the context in which they are working. We are at Galvin are no different. Bringing a general understanding of the project’s purpose can often generate new and creative solutions from unlikely places.

3) Project Specific Discussion Items - As a Project Manager, I always felt like this was the most important part of the kickoff meeting. This is because this is the spot where we openly discuss not only risks to the project, but how to mitigate those risks.

4) Next Steps – Very simply, where do we go from here? Next meetings, action items, etc.

At this point, we’ve succesfully handed the project off to the next runner in the race. Just like in a race, however, there are other handoffs that must occur as the project life cycle plays out. We’ll certainly cover these in later blog posts. In the meantime, just be thankful I don’t actually have any photos or videos from my high school gym class. It would be quite a sight!

Just think about how much time and money your organization puts into creating strategic and formal business plans. The meetings and the brainstorming and more meetings…all trying to account for everything, just so you can avoid surprises. We all know it only takes one bad one and the entire plan can be shot.

You might not realize it, but planning for a web site or web application is much of the same exercise. The difference is we call it ‘Discovery’ instead of Strategic or Formal Planning. Discovery has many purposes, but none so important as trying to account for as much as possible to avoid surprises later in the development cycle.

The trick is to consider what is included in that stack of paper. It’s likely a compilation project requirements, risks to the project, and most importantly, plans to mitigate those risks. Identifying both requirements and risks brings awareness of the possible issues to all project stakeholders. In this way, you not only know what you’re building, but what is out there that might trip you up, and how you’ll deal with it if or when it does happen. In short….no surprises!

Think of it this way, you wouldn’t build a house with proper plans. Show me an architect that cuts corners on your house and I’ll show you an architect without a job. If you’re serious about the project, be serious about planning. It really is that simple.

Now, what does this really mean to someone who does not necessarily manage projects every day? In short, a deliverable is any officially documented information that is critical to the end product of the project. For example, consider the screenshots of a potential new homepage design or the list of things that your organization knows that the new mobile application needs to have. A deliverable is these types of information that contain documented traits that are crucial to the end product.

Now that we’ve highlighted what a deliverable is, it’s important to understand exactly how many deliverables are available for a given project. Sometimes this can be tricky as the types of deliverables critical to a project is dependent upon the industry you are working within. Take that space shuttle that is one day bound for Mars for example, that project is so large that it’s likely to be broken down into many smaller projects…each of which might have 1000′s of deliverables.

As you might guess, producing deliverables takes time and we all understand that time is money. If you connect all of the dots, you’ll start to understand why NASA spends an average of $450 million dollars per mission….it all comes back to the number of deliverables (tangible documents that are critical to the end product) that are required to complete a project.

Luckily, it’s not likely that a web site or web application project will require 1000′s of deliverables or a 450 million dollar budget, but the analogy still works. Identifying which deliverables are crucial to your end product and, conversely which are not crucial to achieving project success within the most cost effective budget structure possible.

The process of indentifying which deliverables are included and excluded is called “tailoring” and relies heavily on experience within managing similar projects successfully. Galvin has successfully completed all kinds of projects, from complex Insurance Rating Software Packages to the simplest of websites. This helps to ensure that the deliverables produced are the right ones for your project, ultimately delivering a superior product at the lowest cost.

For more information on the concept and types of deliverables or on how to better select which ones are the right ones for your project, please give us a call. We’d love to chat more.

Making Your Decision

Generally speaking, any of these platforms would work for your application. Be careful when making your decision, however, that you examine other potentially key details about the project. These factors range from where the application will be hosted to what platforms your organization or its partner organizations, best suited to support?

Once these questions are answered, you must also consider the potential future state of your application. What do you want or need it to be in 2, 3, or even 5 years from now? Will it need to integrate to with other technology solutions within your integration? Will it need a mobile presence? These are just two examples of future state considerations and, depending on the nature of your business model and purpose of the application, there could be many more.

Above all, try to avoid subjective discussions about which platforms are better than others. If you’ve properly identified the other key factors to the decision, you’ll be much better suited to make an informed, objective, decision on this potentially business critical decision.

We understand that compiling and understanding all of these factors can be quite a task, but proper project planning is essential to the success of your application development project. Considerations and questions like these are core to that project planning and a key to making your application not only what you want it to be today, but what you’ll need it to be in the future. For more information on this and how to make it happen please give Galvin a call!

All websites with login access have a “Forget Password” link that allows a user to input their username or email address and a new password will be sent to the user.  This is such a simple application to develop but the user experience can go wrong if it is not designed properly.

It is very easy for the user to get stuck or get confused on what their new password is.  I see a lot of applications developed in which the user receives their new password and is sent to a special webpage to enter their new system generated password.  Once they do that they are let in.  But the user will not remember the system generated password so when they logout and log back in at another time they will have to run through the Forget Password scenario over and over.  So to improve this process here are a few simple adjustments you can make to your functional use case and design:

1. User clicks “Forget Password”
2. User inputs their email address or username and clicks submit.
3. The system flags the account that the user has forgotten their password and that the password must be reset and sends the user a very friendly email. In this email will be link, with instructions, for the user to access a web page to reset their password. On this page the user is presented with two text boxes – password the user will like to set and confirm the password. Put a check in there too so that once the confirm password matches the password chosen a green check mark is placed next to the confirm box.
4. Once the user resets their password let the user in, remove the flag that is set in the database .

It’s ideal to guide the user through the website and to ensure the experience is ideal. Try to avoid system generated temporary passwords that the user will have to input into their login. Allow them to choose their own password.

Guide the user!