Capture screenshots and annotate web sites in your Firefox

Usersnap’s visual communication addon was just approved by the addon team and now we have a “green button”. Hooray!

This is a “must have” addon for every web developer who wants to solve problems with web sites faster and who wants to earn more money by shortening the communication time with the client or inside the team.

Collect ideas and share them with your team

  • Capture and annotate every website.
  • Share and discuss it with your team.
  • Communicate visually and save time.

Annotate screenshots and integrate like a pro

  • Sticky notes, a pen, the pixel ruler and more help you express yourself visually.
  • Integrate Usersnap in your existing workflow and connect it to one of our supported third party tools.

Capture screens in all environments

  • Works on every site, including localhost.
  • Works behind firewalls.
  • Works on your password-protected staging and QA servers.

Every developer will get access and  to the  Usersnap Dashboard where he/she can:

  • Discuss mockups and sketches. Annotate them and push them back to a bug tracking system
  • See advanced client-side JavaScript errors and XHR Logs and browse them.
  • Access extended Information about the user’s session: OS, browser version, screen and browser size and installed plugins

 

Click here to install it (no restart needed)

Read More

Why webcompat.com should do better + a proposal

I really like the webcompat project‘s idea: to allow all users to be able to report bugs on all websites and in all browsers. Let’s take a step back: What are the 3 main problems with bug-reporting in general?

Most of the users are not-so-tech savvy.

It’s true. They know something is wrong, because the website is not working for them, but they don’t know why is that or how to report it. Imagine if they could use the tools they are familiar with to report bugs and to give the developers the data they need without even realizing it. Cool huh?

“It’s working for me”

Thanks to different browsers, standards and different developers a website that one user sees can be completely different for another user. Agreed?

You can imagine the questions the user must answer:: “On which page are you?”, “What are you doing exactly?”, “Did you select something wrong?”, “Did you write a number in your street address as requested?”, “Are you logged in?”, etc.

It’s an option too: the developer (or a QA) will say to the user “It’s working for me”, meaning to the end user - you are doing something wrong, John or Jane, it’s not the website. it’s you.

The end user doesn’t know how to fill-in bugs into bug tracking systems

Majority of the people that can find a bug don’t know how to report it or why to report it.  Most of the companies or projects have 1-2 page howto’s attached to the bug reporting form, but the result is still questionable.

 

The WebCompat way: Now

Webcompat will give all users a brand new way to report bugs. It will also provide for a community which will be able to easily find fixes for the bugs or alternatively, contact the website owners and report them.

There is still one problem with that. The users are still missing the tools which they are familiar with to report bugs. The developers (community of fixers) are still missing the vital information about fixing the bug.

 

The WebCompat way: Upgraded

We can fix that!  Being part of Usersnap’s mission to make this process easier, I can propose a solution and being a Mozillian for almost a decade I believe this will help millions of users to report bugs and to make the web a better place – this is why Usersnap has been created for.

The ideal set of information to fix a bug from the developer’s perspective:

usersnap_ui

  • Obviously, a report of what exactly is not working
  • Information about the plug-ins installed in the browser
  • OS and browser version, at a minimum
  • JavaScript error log and the XMLHttpRequest Log  in case there are problems (we still don’t know that). The worst thing about client-side JavaScript errors is that they happen on the client side, which is a cruel place far away from the developer trying to fix this error.
  • It would also be great to know what the user did BEFORE the error (yes we can do that)

Wouldn’t it be awesome if we could have this information to every bug report, collected automatically.

 

Push to gitHub

And what is the best part of this? All data goes directly to your bug tracking solutions – in this case gitHub and everybody is happy.

Read More