Category Archives: Software

14 Web Site Graders To Test Your Redesigned Site

When you redesign or enhance your site, you make a lot of changes.  You change the content, the design, the front end technology, the back end stack, the user flows, the information architecture, everything.  It is tough to know what you have done right, and what needs help, particularly as it compares to other sites.  These sites can help show you what you have done right, what needs help, and how you compare to other sites.  I use them… and so should you.

  • https://website.grader.com/ – the gold standard of online web site graders. Shows performance, SEO, mobile capability, and security.
  • https://www.semrush.com/ – this site gathers a LOT of marketing information about your site… Monitor this information before and after your cutover.
  • https://validator.w3.org/ – Are you W3C Compliant?  Are you writing valid HTML?  Using this throughout your development will ensure your site is as readable and indexable as possible.
  • http://www.webpagetest.org – How long does the first view of my page take?  How about the second view?  This grader shows you both… just like the Developer Tools in Google Chrome.
  • https://developers.google.com/speed/pagespeed/insights/ – another technical site grader that can give you guidance where to increase performance.  Be careful trying to get 100/100, though… not everything NEEDS to be done.
  • http://nibbler.silktide.com/en_US – Evaluates your site down in four areas – Accessibility, Experience, Marketing, and Technology.  Still useful to get another view of your site.
  • https://www.woorank.com/ – “Run a review to see how your site can improve across 70+ metrics” – Marketing, SEO, Mobile, Usability, Technology, Crawl Errors, Backlinks, Social, Local, SERP Checker, Visitors.
  • http://www.similarweb.com/ – Another great site for a large, corporate web site.  But not a lot of information about performance.  Good to monitor usage and marketing metrics.
  • https://moz.com/researchtools/ose – Moz is known for its SEO tools, and this is an easy dashboard of information to monitor before and after your redesign.  The free version is useful, but the Pro version is even better.  Not a lot of tech help here, though.
  • http://www.alexa.com/ – 7 days for free, the paid version is the only one really useful.  Lots of marketing information is available, though.
  • http://builtwith.com/ – Very technical.  Shows you the infrastructure and software choices made by the development team.  You will be surprised.  Helpful for technology and information security teams.
  • http://www.google.com/analytics  – Free analytics tool.  Tells you who uses your site, how much, where they are from, what browsers, what time of day… a plethora of information.  Including Page Speed.
  • https://www.google.com/webmasters/tools – Free tool that shows you what index errors Google has encountered, things to make your site more indexable, and what your pages look like to the Google Search Crawlers.  Use this.
  • http://www.bing.com/toolbox/webmaster – Everything that Search Console is for Google, this site is for Bing.

So did I miss any tools that you use?  Are any of these ones you have struck off your list?  How do you measure results of your site before and after?  Leave a comment and let me know!

EDIT: Two more sites were recommended to me that help redesign projects, so I am adding them here:

8 Planning Poker Options for Remote Teams

The most common way to size user stories for an agile team is to use planning poker and fibonacci sequence numbers.  But sometimes doing this is difficult if you are not colocated.  I was a big fan of planningpoker.com.  But without much fanfare, they changed their tool to only allow 10 people into their estimation session.  Definitely hoses half of my team.  now i need a new tool to help me size my user stories.  Here are some web based tools that can help me out.

  1. The Original – Planning Poker – https://www.planningpoker.com/ .  This is what I used for years.  But now, the free version is only available to 10 people on your team at a time.  To add more you must pay $25 per month.  Crazy talk.
  2. Pointing Poker – https://www.pointingpoker.com/ .  Simple, basic, very popular, and FREE.  That is all that needs to be said.
  3. Plan It Poker – http://www.planitpoker.com/ .  I like their tag line.  “Completely free to use no matter how large your team.”  Sign me up.
  4. Planning Poker for Hangouts – http://nearsoft.com/resources/tools/planning-poker/ .  If you or your team are fans of Google Hangouts, this is the tool for you.
  5. Scrummy – http://playscrummy.com/ .  This one looks cool… but sounds like it was more of a technology proof of concept than a new product to be launched.
  6. FirePoker – http://firepoker.io/#/ .  Another popular estimation tool.  This one uses angular.js .  Give it a try.
  7. Planning Poker (old version) – http://www.old-planningpoker.com/ .  This one looks to be a legacy install of the original planning poker before the change, and before the redesign.  This might be the answer to my problem.
  8. Agile Estimation for Jira – https://marketplace.atlassian.com/plugins/agile.estimation.3.0_private .  If you are a Jira user,and don’t mind spending money on a plug-in, this is for you.  Not how I would go… but maybe you will.

Which one do you use?  How do you estimate?  Have a tool I missed?  Leave me a comment and let me know!

Debugging Home Run – Problem Step Recorder in Windows 7

4E38RY7KZA4J

I just got an email about a really cool new tool built into Windows 7 that Microsoft used to debug their new platform. It is called Problem Step Recorder. The best thing to do is to post a snippet of the email right here. I think it says everything perfectly:

“In case you’re not aware of this, here is a little known Microsoft tool bundled with Windows 7 that can be extremely useful to illustrate a problem when testing an application. The diagnostic tool called “Problem Step Recorder” was originally produced by Microsoft during the development of Windows 7 Beta to assist their Quality Assurance team in debugging the OS. It uses a combination of screen captures with mouse tracking to record your actions and can be a great way of describing a problem to others. The program is launched from the Start menu by typing ‘psr’ or ‘psr.exe’ in the search field. You’ll get a floating applet that looks like this: When you hit the Record button, the applet tracks your mouse and keyboard input while taking screenshots that correspond to each new action. When you stop recording your session is saved to an HTML slide show that recreates your steps. It also allows you to add comments to further document the problem. I think it can be very useful as an attachment in [your bug tracking tool] for those hard to describe issues or as a “How To” document for end users.”

Which leads to other ways of doing this… you could youse WebEx or Windows Media Encoder to document any bug as a step-by-step. If you use WatiN, Selenium, or VS2010, you can also use their recorders to document any bugs you may find in a web application, hand that to the dev team, and then there is no guessing how to reproduce the bug.

Kudos to Microsoft, and to the folks who uncovered this!

Software Metrics

Being able to measure success for a software development group is a difficult thing. But not being able to show the success of your development group is a dangerous thing. Your management team will want to be able to measure quality, show improvement, and benchmark against industry standards. All the popular maturity models (if you put stock into them) emphasize the ability to measure, react, and improve your quality and processes. My department is no different. We try to remain as flexible and lightweight as possible, and add formality where improvement is necessary. Here are some of the metrics that we collect to measure our success and find ares of improvement.

Code Coverage

There will always be bugs. No matter how hard you try, there will always be bugs in your software. That does not mean that you cannot try to prevent them. One of the easiest ways to do that is to write automated unit tests to validate your code is doing what is expected. You can write your unit tests lots of different ways, and Steve Cornett’s Code Coverage Analysis paper gives lots of different ways to break down code coverage. A great place to start is to aim for 50% coverage of all of your lines of code. And, as Tony Obermeit says in his Code Coverage Lessons paper, your ultimate goal of course is to always hit 100% coverage. You will need to pick a code coverage tool to help measure your success. In my department, developing in a Visual Studio and C# environment lends itself to the nCover open source solution. This solution works well with our CruiseControl environment. Test Driven Development methodologies and mocking tools can help you get closer and closer to covering as much of your code as possible with automated tests.

Defect Tracking

I use the words defects and bugs interchangeably. This I am sure is something that some people would disagree with, but I think that it is close enough. If it is not working as expected, then it is a defect, and it is a bug. Regardless, defects are identified in the development process, system and user acceptance testing process, and in the production environment. The objective is to minimize the number of bugs that are found in the live environments. To do that, you need to encourage the identification and mitigation of bugs in earlier and earlier stages. This sounds fundamental, but becomes difficult to implement. There are lots of methods that you can do to identify, solve, remove, and prevent bugs. You must have a way to measure that these methods are improving your success rate. And that means measuring the number of defects found in each environment – development, system test, user acceptance test, and production. The easiest set of numbers to get in a corporate environment is production defects. There is always a problem management system or help desk that tracks these kinds of things. But as a software development organization, you need to implement bug tracking throughout the entire lifecycle of your software. You can trend the numbers, and make sure you are finding more bugs before UAT, particularly in development. Tools like Bugzilla, an open source bug tracking tool, can help you track, trend, and manage defects in your software throughout its lifecycle.

Support Ticket Management

Software is not a static entity. It is always changing. Just think of all the patches, updates, service packs, and bug fixes that Microsoft releases on its suite of software. In a corporate environment, it is no different. Software management does not end once it is released. Teams of developers will be constantly updating desktop, web based, and console applications based on new requirements and requests from their clients. Problem Management software can be used to help track and trend all of these requests bydata points such as severity (Urgent, High, Medium, Low), priority (Urgent, High, Medium, Low), assessment (Customer Assistance, Required Modification, Elective Enhancement, Break Fix), difficulty (High, Medium, Low), etc. You can measure success agains more complex metrics such as the number of tickets created, number of open tickets, time to resolution, etc. All of these metrics will help you determine how fluid, stable, usable, sustainable, and maintainable your software is. Do not ignore your software or its users once it is released to production.

Analytics

Web Analytics tools can tell you how many users you have had on your site, how long they visited, where they came from, where they went, how they found your site, did they reach your goal pages, did they convert, and did they return. There are free web based tools like Google Analytics, and over the shelf packages like WebTrends and CoreMetrics that can help you measure site activity. Do not ignore these metrics to help you define current activity, make improvements to your site, track your new results, and continue to improve. They directly measure your clients’ interaction with yoru software, and can identify trends that with simple changes can vastly improve your software and development processes.

Conclusion

So… these are some of the ways that we track the success of our software. There are a host of other methods to measure software, such as function points, lines of code, complexity, interfaces, velocity, etc. What ways do you measure your software? how do you define success? What are your plans for the future?

Leave me a comment and let me know what you think.

20 Reasons Why DHTML Layers are Bad

A bit of background before I dive in to the post… My team and I are responsible for developing and supporting the Brand web sites for Bristol-Myers Squibb.  The Brand Teams and external Marketing Agencies develop a concept for their site, and they deliver a fully functional version of the site in  HTML to us to implement.  We take that HTML, squeeze it into our custom content management system, and hook up all of our custom features.  This custom content platform that we call LaunchNet has built in registration management, site search, web analytics, SEO helpers, and a full suite of other tools. 

With an environment like this, managing expectations becomes essential.  Sites need to be streamlined for industrial-strength campaigns involving thousands of concurrent users and possibly millions of site users per month.  From this perspective, DHTML layers is one of the banes of development.  I have broken out why DHTML Layers make me lose my hair into 6 categories: Performance, Metrics and Analytics, Accessibility, Implementation, user Experience, and Search & SEO.

Performance

When using DHTML Layers, your users are now loading multiple pages combined into one, some of which they may not even view, wasting download time and bandwidth.  Pages are slower to download, and are slower to draw inside the browser.  Processing is now heavier on client side, and is heavily dependent on JavaScript, which is known to be a memory hog.

Metrics & Analytics

Layers are not pages.  This is a simple fact, but needs to be stated again for emphasis.  Layers are not pages.  This means that anything that is dependent on the construct of a page will break.  Google Analytics tags, which are designed to fire on page load, will need to be re-engineered to fire on layer loads instead of page loads. 

Accessibility

Mobile users on phones, PDAs, tablets, UMPCs, and other lightweight devices with web browsers will have difficulty.  These browsers are slimmed down versions of their bigger brothers, and do not have all the functionality needed to process JavaScript properly.  Cross Browser Compatibility is very difficult to implement and maintain with DHTML Layers.  You cannot bookmark a layer, either, so your users will not be able to come right back to where they were.  Popup blockers may block the use of DHTML layers, as this is a common delivery mechanism for advertising.  And, DHTML Layers could affect your site’s handicap accessibility.

Implementation

Layers on the site increase complexity, and make maintainability more difficult.  If JavaScript is turned off, any functionality to show or hide layers will not work, so your users will not see it.  Developers will need to spend lots of time to make DHTML JavaScript function with content management systems, particularly when custom functionality is delivered in this way.  And, if layers are big enough, scrolling can become an issue, as the layers may run off the page, hiding content from view. 

User Experience

User Experience is the biggest reason to implement DHTML Layers.  It adds slick new interface to the hum-drum of static pages.  But designers need to keep in mind that performance impacts user experience.  This is an “I want it an hour ago” generation, and waiting even 10 seconds for a page to load will mean your users have left and gone somewhere else.  Layers are a not a standard UI convention for web development, and some users may be intimidated by the change in interface.  And, some folks may perceive layers as “popups”, which is bad for perception.

Search & SEO

Implementing site search while using DHTML Layers is very difficult.  Most search products are page based, and as stated before, layers are not pages.  Your content might not get crawled, or may be crawled incorrectly.  Layers could also cause a problem with search engines.  Your page could end up not getting indexed, or not indexed properly.  Invisible content may also be viewed by search engine crawlers as “gaming the system” or a black hat SEO practice, and may negatively impact your page rank.

Conclusion

When implementing, DHTML Layers, think twice about the impact on other aspects of your site.  Ajax can do a lot of the same kinds of things that DHTML Layers can.  Adobe’s Flash and Microsoft’s new Silverlight products can also deliver great new user experiences.  All of these have benefits and drawbacks that need to be weighed before jumping in.  You may be providing a slick new experience to your users, but you may be creating more problems than it is worth.  There are lots of other alternatives to explore.

My Most Useful Programming Development Tool Ever

The most useful development tool I use makes me more productive on lots of tasks all day long.  I can open just about anything I am working on, and get the job done fast.  It applies colors sparingly to my work, and helps me identify mistakes.  It helps me multitask, working on many things at once.  It understands dozens of different languages with ease, all at the same time, and you can add more very easily.  It has all the qualities of a developer who embraces open source solutions – it is fast, cheap easy to use, and available for download any time on SourceForge.  I have tried its competitors, but this one stands out among the crowd.  It was recommended to me by a colleague, and switching over was very easy.  My most useful programming development tool ever is Notepad++.  I have used the standard Microsoft Notepad, and I have used TypePad, but Notepad++ is head and shoulders above the rest.  Give it a try.  You will convert too. 

Disagree?  What is your most useful programming development tool ever? Leave a comment and be heard.

On The Road to Mix ’08

I consider myself blessed to work for a company I believe in, and in a field that I love.  Working in the field of web development is exciting.  The job is never the same.  The technology is always in flux.  Tomorrow will be different than today.  Bristol-Myers Squibb has treated me well.  And they are doing it again.  I am now scheduled to attend the Mix ’08 Conference at the Venetian Hotel in Las Vegas from March 5 through March 7. 

Mix 07 was a fantastic conference, and Mix 08 looks to be just as great.  Steve Ballmer and Scott Guthrie will be keynote speakers this year.  The sessions look really interesting.  I am hoping to attend the MVC session from Scott Hanselman, some of the Web 2.0 panels, some SharePoint sessions, .Net 3.5 demos, WPF and Silverlight sessions, and some of the UI discussions. 

Last year I documented my trip with blog posts after each one of the sessions.  I hope to do the same this year.  I was criticized by some of my peers last year that my blog posts from each session didn’t really count as individual posts (we have a performance objective to post a specific number of blog entries per year) but as one giant post.  We will see if my online trip report creates as much of a stir again. 

I am really looking forward to Mix again this year.  Take a look at the sessions, and let me know if there are any that interest you.  I can try to attend, attend, and bring back as much information for you as I can.