On Friday, May 17 I had the pleasure of speaking for the first time at Stir Trek, a one-day conference in Columbus, Ohio, that drew over 1,200 attendees (and I understand sold out in just a few minutes). Apparently the name is a reference to the MIX developer conference, for which they were unable to obtain license to use a variation on the name.
I also had the pleasure of presenting for the first time on best practices for making your web site printable, built from my own professional experience, my PrintShame site, and an article I wrote for .net Magazine, among other resources (also linked in the presentation).
With 40 great speakers across 8 different tracks, there was quite a lot to offer throughout the day. Considering the other presentations held at the same time as mine, I was thrilled to get any audience and more excited to see that those who attended saw value in the topic and asked great questions throughout.
Well after the talk I got even more questions and feedback on the session, which I truly appreciated. Since there is no official survey for attendees to give feedback on a speaker, I am hoping any attendees will feel comfortable tweeting about it or leaving a comment here. So far I have gotten one great bit of feedback on Twitter:
Lest anyone think I’m just terminally negative, @aardrian had a REALLY GOOD talk on accessibility. And printability.
(I worked in some accessibility tips during my presentation.)
All other feedback is welcome (including if I was loud enough when the lavalier microphone failed).
While in Columbus I also had the pleasure of having a nice dinner (I arrived too late to make the speaker dinner), visiting the North Market, and, as part of the conference, getting to see a double feature of Iron Man 3 and Star Trek: Into Darkness. All around a good time which I look forward to repeating next year.
It’s been one month since the Boston Marathon was interrupted by two explosions resulting from the detonation of bombs placed near the finish line of the event. One of the topics to emerge from that tragic day was the role that social media played in sharing information about the event as the news unfolded.
I first learned of the bombing from a Facebook post made by a friend. As is the case with most things posted on social media sites, I wasn’t completely sure if it was true or just someone joking around. I checked the CNN web site, and right there on the front page was a breaking news alert that confirmed what my friend had posted. A few minutes later, the image that was displayed along with the news alert was a picture that someone had snapped with their cell phone from an adjacent building to the first bomb site. The first thing that struck me was how graphic the image was compared to the images that are usually supplied from traditional media outlets. Minutes later Twitter, Facebook, and other social media sites were flooded with images and first-hand accounts from people who were near the chaos that unfolded.
I quickly realized that the way this story was being covered by the normal media outlets was… Different. CNN had a feed of images that were being supplied from cell phones and social media sources. Fox News quickly followed suit. Many of these looked like pictures snapped at the front lines of war. Blood, broken bodies, and people missing limbs. This was a shift from the usual news coverage that I was accustomed to.
On Reddit, AMAs (Ask Me Anything) threads started from people who were at the bomb sites. As was the case with a few recent events, consolidated news threads sprang up from members of the site who filled the role of moderators and filtered the eventual flood of news being supplied from the site’s users. Later, after news that the explosions weren’t accidental, dedicated sections of the site were filled with pictures from the event and encouragement to identify suspicious characters.
As has been the case with recent events (such as the tragic shootings in Aurora and Newton), I quickly made Reddit my one-stop shop for news related to the bombings. The reasons for this are simple. The “news” threads that are common for these events are actually moderated very well. There is great care given to making sure that the reports are verified, and in many cases by more than one source. A consolidated list of links to web sites with interesting information are right there for me to visit if I so desire. I can get a quick overview of all the recent developments as reported across multiple news sources in one place, all at a rapid pace.
Unfortunately, there are some downsides to the way that social media is utilized during these events. I previously mentioned sections on Reddit dedicated to identifying suspicious persons. At various points during the criminal investigation, a number of people were incorrectly identified as being suspects and personal information about them was released. These people suffered undue stress and abuse as a result.
So, what’s my point? I feel like this event was a turning point in the way that news is reported and consumed. When the bombing suspect was apprehended, Reddit had 272,000 concurrent users accessing the site. Although questions about the legitimacy of the sites as a “news source” have arisen, there’s no doubting it’s popularity as one. Traditional outlets like CNN have incorporated social media aspects in its reports, resulting in more detailed, accurate accounts of events as they happen in as real-time as possible. I don’t think they have a choice when anyone with a cell phone can break exclusive first-hand accounts. I find myself wondering how different the horrors of 9-11 would have been experienced had they happened last month.
When I say “global,” I don’t necessarily mean the whole world, but really any aggregate pile of numbers for browsers that aren’t culled from your own site or project.
With IE6 finally fading (which many developers will claim is a result of their IE6-blocking sites), the ire of developers has turned to Internet Explorer 7. Given that many web developers want to play with the new shiny (and not worry about supporting older browsers) or hate the extra work that sometimes comes with supporting older browsers, it’s no surprise that disdain for IE7 is high.
It is with that experience that I think casually tweeting global stats and calls-to-action can be irresponsible without context, as this one on Friday:
The Akamai chart shows that IE7 is about on par with IE10 and even fares slightly better than Safari 6. The more discerning viewer might notice that Safari use goes up on weekends just a bit while IE7 use drops off for the same period, suggesting IE7 traffic might be coming from office workers.
Ignore Stats That Aren’t Yours
A few people try to make the point that those numbers don’t apply to their sites, some even try to make the point that this isn’t about browser support at all:
@js_dev @paul_irish you’re not supporting browsers, you’re supporting customers. Job #1 is serving your customers.
As an example, I have a site I was working on last night that gets 7.3% of its traffic (over the last month) from IE7. That’s about one in 14 users. I know I have to support users on IE7 because I look at the stats for the site, not because I look to Akamai, StatCounter, or anywhere else.
Here’s the takeaway I want everyone to recognize: The only browser statistics that matter are those for the site you’re supporting.
I feel so strongly about that point that I am going to quote myself just one sentence later:
The only browser statistics that matter are those for the site you’re supporting.
This Applies to Other Stats
I’ve seen plenty of people discuss window sizes over the years and make generalizations about what sizes to support — even more common in the era of responsive web design. But global screen sizes are irrelevant. Instead, look at the numbers for the site you’re supporting. Even better, look at the viewport size:
There has been a resurgence in discussion of late on print styles, but nobody seems to have any stats for how often users print pages. In the absence of raw data, developers talk about how they use sites and how their circle of contacts use sites. Instead, track it for your own sites and know when pages are being printed:
There are many other cases where developers look to global stats in lieu of tracking their own, but I haven’t written tutorials for them. Now might be a great time to consider writing some of your own for the data points you want to capture.
While supporting your users, and by extension their browsers, is the best approach, it is possible to get so focused on browsers themselves that instead of cutting edge you end up doing the opposite (even if it takes time to become apparent). Take this example from the UK Department for Work & Pensions:
The service does not work properly with Macs or other Unix-based systems even though you may be able to input information.
You are likely to have problems if you use Internet Explorer 7, 8, 9 and 10, Windows Vista or a smartphone. […]
There is also a high risk that if you use browsers not listed below, including Chrome, Safari or Firefox, the service will not display all the questions you need to answer.
The supported list of browsers and operating systems are combinations of Microsoft Windows 98, Windows ME, Windows 2000, and Windows XP with the browsers Internet Explorer versions 5.0.1, 5.5 and 6.0, Netscape 7.2, Firefox 1.0.3, and Mozilla 1.7.7.
During my time here at Algonquin Studios, we’ve made changes to the customer service tools that we use to support our clients, trying to find the best fit for our team and the best level of service for the client. Our most recent change has been, in my opinion, the best–we made the switch to Zendesk, a support ticketing system that tracks all of our emails and phone calls, almost one year ago today and the past year has been a truly productive one for our team (and our clients).
Honestly, there are quite a few reasons why I love Zendesk but today I’m going to share my Top 5, the ones that help make the most impact on our support workload every day:
1) We have exact details about our conversations with clients There’s no more guessing about topics that may have been covered by another support rep or things that may have been promised during a previous conversation–everything’s there in black and white, for us to review whenever we need it, whether we just need to remind ourselves of where an issue stands or we need a quick way to bring ourselves up to date when we’re stepping in to handle something on a co-worker’s behalf.
2) Clients are automatically emailed whenever there’s an update Obviously, an automated update system makes it much easier to keep our clients well-informed. No more worrying about forgetting to send important emails–Zendesk has got us covered! Plus, when we’re troubleshooting a support issue, all we have to do is create one update and we can send it to multiple people, keeping everyone involved in the loop.
3) Managers can log in to view our progress on various issues Zendesk allows our management team to track our progress on support issues without tracking us down for information. With a quick log in, they can see where we are in the support process, determine if the proper progress is being made on the issue at hand, and ensure our clients are getting the attention they deserve.
4) Reporting! We can track things like call volume, response rates, and most importantly, client satisfaction. Information is power!
5) Three words: Knowledge Base Articles! We love it when our clients reach out to us, but we also want to make sure we’re giving them a resource for information they can access on their own. Our Zendesk system actually makes it easy for us to build help/how-to articles that empower our clients to find answers whenever they need them: after-hours, on weekends, or even when they simply can’t get to the phone to give us a call. It’s a win-win situation.
Do you use a system to track your support tickets? How have your customers reacted to the detailed records you’re keeping?
A few months ago I had the pleasure of writing a piece for .net Magazine about print styles (Make your website printable with CSS). It was posted to .net’s web site last month and received an overwhelming one comment. That comment, however, summed up something I hear all the time:
Would be interesting to see some statistics on how many people actually print websites.
For years I have argued that the best user statistics are those for the site you are building. In the absence of global numbers for how many users print web pages, in this post I’m going to show you how you can measure how many (and which) pages get printed from your site by using Google Analytics. I am also hoping those who know everything about Analytics can answer some of my questions.
I want to be able to call the Google Analytics tracking image (__utm.gif) only when the page is going to be printed, skipping unnecessary HTTP calls and the resulting image download (brief though it is). I rely on the CSS @media print declaration to call the image. I also don’t want to write that image call to the page with yet more client-side script when I can assemble it all right on the server.
I still haven’t figured out what the number 5 maps to, but it works. I also found that I need an asterisk as a separator, though I found no documentation explaining it. In the end, the only way a print event tracked as I wanted was when I constructed it as: 5(Print*/Accessibility). In this example, /Accessibility is the address of the page I am tracking.
The other tricky bit is pulling the cookie value and stuffing it into the string. Conveniently I can get to this within our content management system (QuantumCMS, which you should use) on the server side. Many others (if not most or all) have a similar ability. At the very least you have to include the __utma and __utmz values, passed as encoded parameters for utmcc. Without these, my tracking would not fire.
The Completed Query String
For ease of reading, I will break the string to a new line at each &. This represents what is generated when I visit the careers page on the Algonquin Studios site using Opera.
Now that you have the query string and the Google Analytics tracking image, you just need to call the image when the page is printed. All you need to do is embed a style block at the top of your page with the print media query, and call the image within it:
If you read my post on embedding QR codes, then this code will be familiar — I use header::before in that example. As such, I use header::after here so you can use them both keyed off the same element (header) without conflict.
If you look closely, you may have noticed that my event parameter looks like 5%28Print*/Engage/Careers%29 instead of 5(Print*/Accessibility). I URL encoded the parentheses on the entire string to make certain that they do not conflict with the parentheses in the CSS. If you don’t do that, the browser will get confused and fail to load the image.
Once you have the CSS in place, I recommend going into HTTP Fox or the Chrome Developer Tools to make sure the image is called when you fire a print preview (save paper!), and then to make sure it has the parameters you expect — particularly the utme value:
Checking Your Google Analytics Report
Assuming you’ve verified all is working well, you just need to run a report for events in Google Analytics. Bear in mind that Analytics isn’t up-to-the-minute, so you may need to give it some time to capture all the data.
Log into your Analytics account and make sure you set the report date to the time period where you rolled out these changes. Choose “Content” from the “Standard Reports” on the left side. From there, expand “Events” and then select “Top Events.” You should see “Print” as one of the items in the “Event Category” column (you may need to show more rows).
Click on the word “Print” in that grid and you will see all the pages that were tracked (ostensibly because you or a user printed the page).
From here you can run a secondary dimension to cross-reference this with more information. In my example, I tested different pages in different browsers so I could quickly verify the cross-browser support. You can run screen resolution, landing page, or any other dimension that you think might be handy to compare.
I am just adding this to my own site, so I don’t have any numbers to offer as part of this post. However, if you implement this please feel free to let me (and everyone) know how many users you have who print and for what site. I don’t expect the numbers to be high, but I do expect to see it happen here and there.
If you have any additions, corrections or suggestions, please let me know. I am still unclear how all the Google Analytics query string parameters come together and exactly what they all mean, so there may be some optimizations I can work into it.
Over the past few years, my role at Algonquin Studios has expanded to include the front-end development of QuantumCMS, our in-house content management system. In that time, QuantumCMS has changed a lot. We’ve crushed bugs, added new features, and enhanced the user interface
The release of QuantumCMS 5 is slated for May 1, 2013 and I’m really excited about this version. Not only have we redesigned the interface, but we’ve also added new features, vastly improved some existing features, and upgraded the code under the hood.
Here’s a look at some of things that you can expect in QuantumCMS 5:
We’ve given the interface a clean and fresh look that’s easy on the eyes, but the layout is largely the same as previous versions, so you won’t have to hunt around for anything.
We’ve built a new site tree control from the ground up. In addition to new icons and styles, the tree now includes drag-and-drop page moving and sorting in all supported browsers. We also added a feature to indicate when a page has drafts. In such cases, a small pencil is displayed over the page type icon.
This release will introduce a brand new file manager. The file manager is no longer available as a tab in the left pane, but now opens in a new window so you have more room to work. The new file manager supports drag-and-drop for moving files and includes basic image editing features like resize, crop, and rotate. In modern browsers, you can even drag files from your computer into the window to quickly upload them to the server. And yes, I said files! With the new file manager, you can upload multiple files simultaneously.
We’ve added a set of new screens that can be used to help define business rules and manage content that is specific to an area of the site. A section is simply a page and all underlying pages. In QuantumCMS, you can define any page as the root of a section and apply custom content like Linked Pages and Properties that will appear on all pages within that section of the site.
Although there are many potential uses, we believe that this will be particularly helpful for sites with multilingual content, mini-sites, or both. Making use of this feature requires some template updates, because the functionality must be coded to match the site’s business rules.
Linked Page Images
We noticed that a lot of web sites associate images with their links so we’ve attempted to make that easier by adding a Link Image file picker to the Linked Pages screen. Much like Sections, the Linked Pages feature is implemented uniquely for each web site so template updates are necessary to make use of this feature.
Open Pages in New Window
You may have noticed that there is now a check box on each page that is labeled, “Open in a new window.” By checking that box, all links to that page in the navigation, search results, and site map will open in a new window automatically.
I’ve saved perhaps the best for last. In QuantumCMS 5, we’ve made a bunch of code updates to streamline the page rendering process. That ultimately means that sites on this version will load faster. Additionally, we believe our new Sections feature will further this for those clients that make use of it. We’ve made major strides to accomplish this and we believe that it will pay dividends for our clients as well.
I hope that you enjoyed getting a sneak peak at our upcoming release. Please feel free to share your feedback!
A combination of people who are far smarter, far more well connected, and in timezones that allow them to write about this sooner, along with all the Twitter chatter, has already hashed out the major details. As such, I will link to them below. I would be a terrible blogger if I didn’t offer my opinion, however.
Any developer who is complaining that this means there is another browser/engine against which they will need to test has been doing it wrong.
Web developers should always test against different browsers, regardless of their engine. In particular, WebKit has so many nuanced implementations that not independently testing against each browser that uses WebKit belies either a lack of understanding of how WebKit is implemented or laziness.
If you aren’t sure what is different between each WebKit implementation (Chrome, Safari, Android browser, Opera, etc.), I encourage you to read my post “WebKit Will and Won’t Be the New IE,” where I provide a high-level overview of these variances.
At this point it doesn’t mean a whole lot.
Google will argue this is better for users. Apple will argue that Google took its ball and left. Opera won’t be arguing. None of that impacts users because we have mostly done a good job of promoting standards-based development. I again refer you to “WebKit Will and Won’t Be the New IE” for how poor testing can impact users, but that’s not a function of the engines.
That’s just speculation on my part.
For a specification to become a W3C recommendation, there must be two 100% complete and fully interoperable implementations, which basically means two browsers need to support it. When Opera announced the shuttering of Presto, that left Trident (Internet Explorer), Gecko (Mozilla), and WebKit (Safari and Chrome) as the remaining engines (of measurable size). Essentially, two out of the three of them had to agree to implement a feature.
With Blink, provided the W3C recognizes it as a stand-alone engine, there is now one more engine back in the mix, essentially returning the count to where it was in February before Presto’s wind-down (to be fair to Presto, it’s expected to exist in the wild until 2020, but with no new feature development).
I am hoping that this is a good thing for standards.
Blink won’t be using vendor prefixes (even though it will have inherited some), so I consider that a step in the right direction. While I think this matters to developers, I think it matters even more to standards.
From Peter-Paul Koch:
Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.
First some bits from The Twitters:
Let’s bring back the Netscape engine and call it Spacer! RT @codepo8: After blink Microsoft might bring out a new engine called marquee
Any reputable company will tell you that customers are your lifeblood–without them, your business can’t exist. It’s crucial to keep them happy, and a large part of that is managing their expectations. When I first started working in this field I underestimated just how important expectation management can be to customer satisfaction but I quickly learned from my managers to always keep this idea in the back of my mind.
Imagine your experiences at various restaurants: if you’re stopping for a quick bite to eat at a fast food restaurant, you’re (typically) expecting low quality food, but you’re expecting it to arrive quickly and not put a sizable dent in your wallet. If you’re booking reservations at a Michelin star restaurant, the exact opposite would be true. However, in both situations, it’s possible to be completely satisfied with the product and service you receive simply because of the different expectations that you started with.
Although it’s a different situation, the same concept can be applied to providing software support-a large part of how happy customers are with your company is due to the expectations that are initially set and then either met or not met on a regular basis. While it’s important to always strive to provide the highest level of support possible, it’s also extremely important to set realistic expectations. Here are a few of the things I like to keep in mind in order to better manage our customers’ expectations:
Consistency is key. Providing fantastic service one day and poor service the next will frustrate your customers, since they’ve come to expect a certain standard. Making yourself available to assist a customer after normal support hours will set the expectation that someone will always be available to do provide immediate assistance, regardless of the time of day. Make sure that’s a commitment you can follow through on, every time.
Always mind how you word things. Sugar coating may make things sounds better to your customers, but if it leads to the impression that you’ve promised something and failed to deliver, you’ll just end up looking bad. You should always be kind, helpful, and accommodating but don’t feel pressured to say or promise anything that you can’t back up. A temporarily frustrated customer now is better than an enraged customer in the future.
Make it clear what you can and can’t assist with. While always trying to help your customers as much as you can sounds like a great idea, providing partial assistance with things you’re not familiar with isn’t. Unless you’re prepared to take full responsibility for any consequences or you’re equipped to continue assisting with that issue going forward (see the first bullet!), it’s best to have them contact the appropriate support team for help.
Make sure your customers are kept in the loop.This is a rather broad statement, but it’s an important thing to remember-nobody likes being left in the dark, especially when a product or service they’re paying money for is involved. Even a quick note, letting them know you’re still working on their issue, will reassure your customer that they haven’t been forgotten and are still a priority for you. Expectations for great customer service are higher than ever and, thanks to technology and social media advancements, there are a ton of quick, easy methods and tools to keep your customers “in the know.”
I highly recommend sharing these tips with new employees at any company, as they can help expedite the growth from rookie to seasoned veteran in the customer service world. Every company has different support procedures, but these concepts should be universal whether you’re in fast food or software development. What are some ways you’ve failed to meet customer expectations? What are ways you try to meet them on a daily basis?
There’s nothing like the old cliché, ”You never get a second chance to make a first impression.” In the software development business, this quote definitely holds true. Earning a client’s trust will hopefully happen the first time you meet with them to discuss their problem and work to identify a business solution, but once you gain that trust and come to an agreement to help them achieve their business solution, it doesn’t stop there. There are other points during a project that provide an opportunity to make a good impression, to ensure a successful project, and a great client relationship in the future:
Project Kickoff Meeting
At the start of the project we usually conduct a project kick-off meeting. Sometimes this meeting is with your initial contact, on whom you’ve already made a good first impression (or you wouldn’t have the job), but often this meeting will introduce you to the client contact who you’ll work with throughout the course of the project. It’s important to convey, during this meeting, that you understand the company’s needs and that you’re willing to listen to their ideas, suggestions, and pain points. Here are a few examples of what I do in these meetings to help ensure I’m making a good impression:
Come organized and be prepared. Make sure the client knows that you understand their problem.
Ask questions and don’t assume you know any answers. You’ve got questions for a reason; assuming the answers will ultimately leave you lacking vital information you’ll need later on.
Listen to what the client wants and, if what they explain doesn’t make sense, see if you exlpore new ways of “explaining it” with them. I often have clients draw what they want on a whiteboard. While the drawing might not be an accurate representation of what will be needed in the long haul, having the client take control and talk things out while sketching is a good way to get them to focus on the goals of the project and gives you a great opportunity to gather requirements.
Be sure someone from your team is taking diligent notes that you can refer to after the meeting and throughout the course of the project, making sure nothing gets missed.
After the meeting, send the client an email, summarizing all the details and plans that were discussed.
First Client Demo
One of my favorite things about the software development process is seeing the client’s reaction when you first show off the solution you’ll be providing. Depending on the size of the project, and how many meetings it took to fully gather the requirements, the amount of time between kick-off to the first demo could be months-a lot of hard work goes into the requirements and construction, so you don’t want this first demo to go poorly. Having a bad demo might strip their confidence in you and what you’ve been striving to achieve with them. Here are some suggestions that have helped me ensure a great initial demo:
Manage the client’s expectations about what they’ll see in the demo prior to arriving for your meeting. If you don’t know what to expect, they might be disappointed when that “cool feature” they’re all waiting for isn’t quite done.
Try not to demo something that isn’t believed to be fully developed. Works-in-progress will probably throw errors and not perform to expectation, so save them for next time, when they are done!
Try to populate the demonstration to utilize data that the client will understand. This may seem subtle to the developers, but having the client understand exactly what they are looking at will generate more productive questions and weed out unnecessary ones. If the client is fixated on “Why do all the fields say ‘Testing A’?” they won’t be focusing on whether you’ve accomplished the task at hand.
For each screen or process you review, be sure to ask if it makes sense and take note of the reaction of the customers. It is usually pretty easy to tell from their expressions whether or not they “get” what you just showed them. Don’t underestimate this step-if you go through an entire demo without offering an opportunity for questions you’ve probably lost them.
As you can see, there are at least three different times where you need to make a good “first impression” throughout a project. This idea has been hammered home to me recently in my personal life, as well, as I’ve interacted with two separate businesses where my first impression of them was less than impressive. I thought to myself “Why would I spend my money on a product when I don’t have confidence that my best interests aren’t being considered?” Make sure you’re considering your clients’ best interests when working on projects for them and make sure the impression you’re providing leaves them confident you’re doing just that-putting them first!
I have been associated with software development for over 35 years. I wrote my first software using assembly language. Every thing that executed in our software in those days was written by us. We did not have libraries to link to or objects to include or API’s to call. I am not trying to imply that software development is easier now than it was before. The challenges faced by today’s developer are different than what we faced. Software written in those days accomplished less with more lines of codes than today’s software. The technologies, methods and many other aspects of software development may have changed but the basic rules that we followed those days still hold value.
Let me introduce you to those basic rules that I always followed. I call them the conservative values of software development.
Keep it simple:
One of my professors of assembly language programming gave us a challenge as our first assignment. We had to write a simple program to determine if a given number was prime using a pseudo language which contained only one executable statement and one declarative statement. It took us hundreds of lines of code to accomplish that simple task. The lecture that followed that assignment taught me a life long lesson: Simple programs are easy to debug, easy to follow, and usually more efficient to execute. Writing a complex line of code that can accomplish several tasks may make you feel good about your coding skills but pray that no one else has to debug or change that code some day, because they won’t agree that you’re a good coder. Accomplishing the same set of tasks in few simple lines of code will be better in the long run. Simple code is more readily reusable. I’m not preaching that you shouldn’t use all the tools at your disposal, just that you should remember to keep it simple.
Don’t lose focus on your target users:
This rule is more applicable to today’s developers because we use so many different apps in our day to day lives that using software becomes a second nature to us and we start developing our software to behave the way we want our software to behave, which can lead to many assumptions and prejudices of user requirements on our part. You’ll only work once to build the software but the user will use it many, many times to help them take care of some important business. Your number one goal should be to make sure that they can accomplish the tasks important to them in most efficient and simple steps. They might be wowed by fancy features the first few times they interact with your software but, in the long run, its efficiency and ease of use will be the only things that will matter.
Making your software mistake proof:
Making assumptions about a user’s requirements is as bad as assuming that all users of your software know what they are doing. Yes, they do know their business and probably know what they want to accomplish but you can’t expect them to always enter the right values in the right fields and chose the right action. But you shouldn’t attribute their mistakes to lack of knowledge, repetition can often create “slip-ups” and if little mistakes create a lot of “fix it” work, then failure isn’t just theirs but your software’s, as well. You know the business rules and you know what mistakes can corrupt the data or corrupt the process–put in the extra effort to edit for those mistakes. Your users may not realize it, or even appreciate it, but you’ll create a more efficient process for them and that should always be your goal.
Software Developers are like people who build roads. Basically, we’re providing a means to get from Point A to Point B in the most direct way, saving our users time and hassles. Remember not to build a scenic road, full of curves and bumps, if you’re building it for drivers who use it to get to work every day!