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!

Post from: The Galvin Blog

Better User Experience on “Forget Password” Processes

In 2006 Galvin Technologies started implementing Salesforce.com into the company.  Since then our company has purchased several licenses spread throughout our employees.  It has become an application that is necessary to the health of the business.  In addition, Galvin Technologies, an Indianapolis Web and Software Development company, does Salesforce.com project development work for clients. Over the past four years I personally have become a Salesforce junkie so I wanted to share with you my 5 favorite things with Salesforce.com.

1. No Software – Salesforce.com runs off this tag line.  Is is a SaaS application and runs in a hosted environment.  We don’t have to install any software or buy any hardware.
2. Workflows and Business Rules- Using Salesforce you can develop business workflows based on various business rules.  For example, one of our custom workflows allows for easy processing of new work orders.  When an opportunity’s stage is set to “SOW Signed” and Contract Signed = “Yes” then a Sales Order Form is automatically generated populated with fields from Salesforce, attaches a copy of the client work order and contract, converts it to PDF and sends it to Accounting and Production for processing.  What use to take 10-15 minutes for someone to do now takes as much time as it does to click a button.
3. AppExchange – Hundreds of apps to browse and implement into your Salesforce account.  A few of our favorites are the ExactTarget Application, FormFactory and TimbaSurveys.
4. Usability – Hands down, Salesforce.com has one of the best usability features I have seen.  It is simple and understands how the user navigates throughout the application.
5. Client Support – Salesforce.com would probably consider Galvin one of it’s smallest clients but the personal support is remarkable.  Every time we submit a ticket to Salesforce.com it is followed up with an email and a phone call.  When the ticket is closed they follow up again with an email and a phone call confirming I am satisfied.

Post from: The Galvin Blog

My 5 Favorite Things with Salesforce.com

Originally, Steam was used as a way of purchasing and downloading Valve games online, as well as being the epicenter for Valve’s online multiplayer games. Despite starting relatively small and in-house, it was rather obvious just how important Steam was to the gaming community. Now, gamers could download and play the games as opposed to driving to a store to purchase a CD that could very easily be scratched or destroyed. Now, Valve has over 25 million users, over 1,000 titles from various different publishers available for purchase and download, and is estimated to control roughly 70% of the digital distribution market. What also makes Steam special is the ability for one user to download the same game on multiple PCs because each user has their own account name and password that can be accessed anywhere. If you download Half-Life 2 on your home computer, you can access Steam online via your laptop and download Half-Life 2 onto that one, as well. Thus, you don’t have to buy two different copies of Half-Life 2 to install on two different computers; the license-to-use needs only to be bought once.

You don’t have to be a gamer to enjoy the benefits of a Steam-like system. Businesses around the world are using similar systems known as Software as a Service or SaaS. Through an online third-party group (the gaming world equivalent being Steam), the user can access business applications and get software upgrades via the internet. This eliminates the need to equip every device with its own personal license for the software in question, greatly reducing cost. The compact disc also becomes irrelevant, and concerns about damage to the disc are rendered moot. The SaaS model of software access, for the usual monthly fee, is an innovative way for businesses to obtain access to software needed as opposed to licensing every unit in the business for use.

Post from: The Galvin Blog

Software as a Service: Licensing Multiple Units in the Digital Age

When the Indiana State Republican Party (INDGOP) approached Galvin, they were not satisfied with their current website. Navigation was difficult and the site was overall relatively disorganized and the site did not integrate with two major internal applications – Salesforce and RPort (INDGOP’s internal proprietary database). In short, INDGOP wanted something fresher, more vibrant, user friendly and navigable. They wanted a website where people could come and get information without a hassle, a website that better represented the INDGOP and the 92 counties.

Galvin sat down with the INDGOP and documented all of the functional, technical and design requirements so that no stone was left unturned. After the requirement process was completed it was decided by both Galvin and the INDGOP that the project would work best if done in phases. The first phase, the current website, would have the main components required to be fully functional along with 92 microsites for each of the Indiana Counties.  While the next phase could potentially have microsites for Candidates and Activists.

The main INDGOP and county websites now have an “Action Center” so that visitors have direct access to the information they want– the links are readily available on the homepage for immediate usage.  At the Action Center, the public can come to Join the Team to volunteer for State or County campaign tasks, write letters to the editor, search for talk radio stations and receive call-in advise, make a donation, get contact info for state and local officials and have access to the INDGOP Twitter and Facebook sites, all in one general hub.

Users can also now create their own MyIndianaGOP account and receive the News and local officials that are tailored to their county.

The County microsites were designed so that if an official running the site was suddenly unavailable for any number of reasons, the state has the ability to step in and run the site itself. If a user has an event that they would like to be included on the State INDGOP or a specific county’s website, the INDGOP and counties have the ability to receive these event submissions and add it to the corresponding website or disapprove it all with one click.  To eliminate dual data entry for the INDGOP and the Counties, Galvin was able to successfully integrate the Salesforce system and the RPort database into the website.  By providing these key integration points, Galvin has provided the INDGOP one point of data entry for more consistent data and more time to focus on other tasks.

During the process of building, we have trained the INDGOP personnel so that they will be able to run the site – and microsites – on their own. In the end, we have created a system that is not only immediately functional, but will be able to be sustained by the INDGOP on their accord. The result is a site that combines usability and interaction to create what should be a very successful online network for the INDGOP.

Post from: The Galvin Blog

Indiana State Republican Party Re-Design

Dvorak Simplified Keyboard

What would happen if, out of nowhere, a company came out with a better MP3 player than Apple? Better storage, more functions, etc. for a better price? Well, it’s happened. Multiple times. Some competing MP3 players offer all of these superiorities, but have failed to achieve the prestige of the Apple iPod due to its seemingly ever-increasing popularity. There are multiple reasons why the iPod has managed to own the competition, including – but not limited to – visual appeal of the product and the huge advantage that Apple has developed in advertising. Even if a product comes out on the market that is proven to be superior to the iPod, there’s a good chance it won’t surpass Apple’s stronghold on the mind of consumers as a whole.

A parallel can be drawn to the existence of a keyboard you might not be familiar with. The modern keyboard layout was created before computers even existed so as to prevent typewriters jamming. While the “QWERTY” layout (the most common modern keyboard) did indeed solve this relative annoyance, there was a concern about the fact that there existed only one vowel on the home row, a feature that still exists today. While effective in its purpose, the need for the layout of QWERTY was rendered moot by computers, machines that don’t have to be concerned with jamming in the same manner of typewriters. However, consumers had gotten extremely comfortable using the QWERTY, and it was perhaps inevitable that electronic keyboards would have the same character layout. Even today, the vast majority of the computer-using population uses a very slight variation of the original QWERTY. Look down at your hands, and there’s an exceedingly good chance that on the home row (middle row of letters), you will find exactly one vowel: “A.” One row up the first six letters will probably be Q-W-E-R-T-Y. The remnant of the typewriter-dominant past still exists.

Despite the fact that QWERTY prevented mechanical jamming on typewriters, there were concerns about the layout of the letters and the strain that was placed on hands during the action of typing. A different keyboard was created in the 1930s – the “DVORAK” – according to what letters were utilized most often and the way that people physically type; the most common characters are more accessible in DVORAK, and the lesser used are placed in more remote areas of the board. A, O, E, U and I are all on the home row, for example. Everything about the DVORAK points to superiority over the QWERTY. But, although the DVORAK is easier to get a hold of now than it was thirty years ago, the QWERTY still has the market by the throat. Yes, it would take you a bit of time to get used to the DVORAK, but carpel tunnel would be much less of a concern for you than it is now. Your efficiency would more than likely see a noticeable increase. But the QWERTY is what we are, as a whole, most comfortable with. The QWERTY, like the iPod, is what we use despite evidence that we should move on to the DVORAK, the usability pioneer in the keyboard world.

Our Interactive Portfolio

We at Galvin Technologies like to think of ourselves as the DVORAK of website usability. It’d be easy for us to go the same route as everybody else and design websites according to the QWERTY layout the industry has provided us, but we choose to take a step or two out of the box. We don’t want to completely buck the trend, and do pay close attention to the requirements of business models, but try to take into effect usability aspects: the QWERTY vs. the DVORAK. Just as the DVORAK was created with the user in mind, we design websites with the users in mind. The QWERTY was useful when it was necessary, but it’s time to move on; sometimes it’s better to come up with something new and a little different, more user-friendly, than continue to follow a trend of blatant usability inferiority.

Post from: The Galvin Blog

Comfort of Popularity vs. Usability: Bucking the Trend

Ok. You have decided to make a monumental decision: you are going to hire an architectural company to build a new house for you. After months and months and what has to equal hundreds of thousands of dollars, you drive to your new home, walk in and…realize things aren’t quite right. You flip the switch for the garbage disposal and the upstairs toilet flushes. When the dryer runs, the air temperature drops thirty degrees. This is not what you had in mind. You have wasted lots of time and lots of money on a product that, in the end, was nowhere near what you wanted.

This is a legitimate concern in the software engineering and development world as well as any other type of construction. It’s easy to just build a house or just design a car if a customer asks you to, but there is so much room for error and disappointment, cost in both time and money, that we choose a little more intimate of a route. Not only do we develop websites for our clients, but we also develop business systems. To do this in at our most efficient level, we go over the functional requirements of the system with the client and follow that up with use cases.

Some sites can be basic, flat html pages, where the user can visit multiple pages via links and learn about the company, the products the company sells, and navigate pages without really doing anything other than that navigation. For example, a florist shop – let’s call it Fiona’s Flowers, based out of Tampa – has a website with a few pages that give the company’s bio, some contact information, some pictures and a list of various plants and boutiques one can purchase at the shop. All in all, it’s not much more than an online Power Point presentation that the user navigates. One can’t buy anything online, nor can one compare prices to other companies when Fiona boasts that her prices are the best in the area.

Now let’s backtrack and say Fiona hasn’t had this business designed yet, much less a website, but she knows what she wants there. She comes to us and says, “Hey, I’m going to be building a floral company. I have nothing except my idea and how I want it to work.” It is then our job to define the functional requirements – what Fiona’s system has to do – for the business system and the company. She has to have customer’s able to purchase online, has to have a shipping service and options for shipping, has to be able to compare prices for each and every plant she sells with the competitive market, etc. We end up with a laundry list of the client’s desired functions for their system because we want to design a complete system for you. Software engineering is, in essence, no different than engineering a car; what are the pieces and parts I have to build to make all this happen?

We’ve listed what the customer wants and documented what this product should do, and now we have a laundry list for system purposes – the functional requirements. Once we have that, we lay it all out into modules, creating a model for everything from application to the storage database. After looking at this list and modules, each building block in the application model, we start creating use cases.

Let’s look at an insurance company, for example. One objective for a use case, the process associated with it, might be creating a quote and saving it to the database for future viewing. The functional requirements are the ability to print the quote, generate a pdf file for emailing, etc. A use case for this quote creation would documents the flow of a user’s steps to creating a quote, from interface appearance, generating a quote number, attributes of the policies available and coverage, and so on and so forth. The use case basically walks through the steps of how a user uses the web page of the insurance company and its components.

Also documented are the specific business rules applied. The customer enters information on the screen  and clicks “save.” The next step would be applying a business rule according to what is laid out in the use case – what has to happen. A quote number needs to be created. What numbers are generated? How are they generated? These are business rules that have to be applied to meet the functional requirements discussed earlier. What happens if the driver’s license isn’t validated or wrong information is entered? What happens if a license number has expired? These are logical business outcomes that need to be very clearly laid out. If a user wants to take a policy on Dodge Viper and the business isn’t willing or able to take on that car value, what is the process that needs to occur that sends a message of refusal? The response is documented in the use case.

---

We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone.

---

Use cases are important because it forces both our client and us to agree on everything that is going to happen. We get sign off on everything before we sit down and design the product. We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone. It’s not only a system for agreement, but it gives the developer, who doesn’t make much contact with the client until the use case is developed, a very specific idea of what they’re going to be building and how to go about doing it. As the blocks agreed upon in the functional requirements are built, what we had previously discussed and agreed upon is enforced.

So, back to the house example from the very beginning. If we built houses, we would sit down with you and discuss – and agree upon – the functions for everything in the house. This switch will turn on the garbage disposal, this will turn up the heat, and this will lock the door. There’s no room for confusion or the possibility of a devastating mistake either on your expectations or our construction. The whole purpose is to get confirmation that what we’re developing is in essence what you need before the product is created. It saves you money. It makes us efficient. And it makes the products stronger, better, and faster.

Post from: The Galvin Blog

Functional Requirements and Use Cases: Avoiding Accidents and Mix-ups in System Engineering

Tight rolled pants was a fad we all followed.

Define Your Requirements
When making a technology decision you must first determine your business requirements. When we engage into an application development project our first group of deliverables consists of a functional requirements document. This document outlines the functional requirements necessary to the business processes. When this is done first then it makes decisions and budgets much more accurate and profitable. But typically we see companies following “fads and bandwagons” of new and popular technology. They use these technology fads because their competition is or they were sold incorrectly. As a result poor decisions result in lost profits. But when you instead become a pioneer in the application you are accelerating your momentum for for success. You are defining the requirements and the direction for your business.

Don’t Overreact to New Technology
Collins states that “leaders of good-to-great companies respond with thoughtfulness and creativity, driven by a compulsion to turn unrealized potential into results. They do not take reactionary measures, defining strategy in response to what others are doing. They act in terms of what they want to create, and how to improve their companies, relative to an absolute standard of excellence“. Don’t let the technology fads overwhelm you. Instead, know the direction of your business and the technology can be created to enhance that. A client of ours shopped for ERP software packages to run their business. Because of the complexity of their business and because they were first to market with a product they determined to custom build the application based on their specific business requirements. As a result, not only are they a leader in the market because of their product but their competitive advantage has become their application and how their business runs on it. Now, their competition is coming to them requesting their software to be implemented into their business. They have become the pioneer and leader because they did not follow a fad or jump on certain bandwagons. They are growing because they know the direction their business needs to take and they have defined the application to support it.

Why Are You Joining the Social Media Fad?
In another document supplied to me called “How Clients Buy” published by RainToday.com it indicates that social media/online communities are near the bottom of the list of what influences companies to buy professional services. I agree and disagree with this statement. I disagree with it because social media/online communities help create popularity which generates brand awareness and familiarity, which happens to be the most popular way clients buy professional services. So social media/online communities can help get your foot in the door but it can’t close the deal which why I agree with the statement. Don’t hide behind social media/online communities. Not all of your buyers on there or even worse the wrong buyers are there.
Have a specific strategy with measurables. We use SalesForce to measure all of our activity, including that on social media sites. So I know exactly how profitable our business is from online activity as well as how much time we should be spending in those communities or what online social activity I need to improve.

Post from: The Galvin Blog

Technology is an Accelerator: Be a Pioneer and Not a Follower

Search Engine Marketing:

• Andy Beal’s Marketing Pilgrim, feed
• Conversation Marketing, feed
• Daily SEO Tip, feed
• Dir Journal, feed
• GrokDotCom,feed
• Matt Cutts, feed
• Search Engine Guide, feed
• Search Engine Journal, feed
• Search Engine Land, feed
• Search Engine Watch, feed
• SEO by the Sea, feed
• SEOmoz, feed
• Techno Marketer, feed
• The Official Google Blog, feed

Web Development

• 456 Berea Street, feed
• A Source of Inspiration, feed
• Cre8pc, feed
• CSS Beauty, feed
• CSS Tricks, feed
• DevSnippets, feed
• Janko at Warp Speed, feed
• NETTUTS, feed
• Posh CSS, feed
• Script & Style, feed
• Signal vs. Noise, feed
• Sitepoint, feed
• The UX Booth, feed
• Usability Post, feed
• Woork, feed

Post from: The Galvin Blog

Web development blogs and search engine marketing blogs

Because of the complexity of the web software applications built by Galvin Creative Technologies we need a partner we can rely on.  Bluelock’s VMWare has helped our company and our clients grow within a very robust infrastructure.

Post from: The Galvin Blog

Congratulations Bluelock

Every web application project we approach always starts with a discovery phase.  During discovery, we assess the business problem, the solution needed, the budget, the timeline, the requirements, and the technology environment.  Our most common approach is to develop in a .NET environment, but there have been times we have had to develop in PHP or Ruby on Rails.  Fortunately, our web applications development team is diverse and very experienced in these languages.  Therefore, during discovery we are able to determine the best application development approach based on various requirements.  There have been times we have consulted and determined Ruby on Rails is the best approach to take.  Here are a few reasons:

1. Technology Environment – If we are presented with a Linux environment and it’s a brand new application our lead architect may architect a Ruby on Rails solution.  It runs best within a Linux environment and many object-oriented methodologies can still be used.
2. Timeline -  If the timeline is very tight then a Ruby on Rails solution may be developed.  Our application development team will have to balance this vs. the technology environment and the long term vision of the company and future applications.
3. Budget – If the budget is limited and the business requirements are limited then our application development team will architect a Ruby on Rails solution.  Ruby on Rails works nicely on a tight budget.
4. Fun – We typically develop in .NET but there are times where our developers just want to get their hands into something new.

Below is a case study of Galvin Creative Technologies‘ most recent Ruby on Rails development project.

Online Placement Test for University of Indianapolis – The Modern Languages Department at the University of Indianapolis allowed incoming students to take a placement test for German, French, and Spanish language classes.  In the past, this was done on paper, had a manual grading process and was then approved by the registrar.  This was a time-consuming process and the incoming students would not be notified until weeks after they took the placement test.  Galvin Creative Technologies developed an online placement test system that allowed incoming students to take the test online, receive an immediate score and immediately be placed in the appropriate class.  Now, instead of waiting weeks to be notified, an incoming student knew the results the moment they hit submit after taking the placement test.  The other major benefit of this application is how it communicated with the registrar office.  The test scores and placements were immediately sent to the registrars office for verification and final approval.  A few other features of the online placement test system included:

• An administration section to review student scores, monitor tests, manage test content and answers.
• A streaming audio section built with business rules that only allowed the audio to be listened to twice before answering a question.
• Language translation for French, German and Spanish.
• A built-in onscreen keyboard for special German, French, and Spanish characters.
• Custom calculations for a complex grading system.
• Direct communication with the registrar.

Although .NET is our most common approach we are thrilled to be developing in Ruby on Rails.

Post from: The Galvin Blog

Ruby on Rails Development