Collaboration of the kind where everyone is involved, and able to discuss projects and tasks while you as a manager still having full control over what they can see and do, can be tricky. ActiveCollab is a project collaboration hub for teams that solves that problem. And with Usersnap hooked up to activeCollab, you can easily gather feedback during your development process. Having all project data in one, centralized place is extremely valuable as everyone knows where to get the most up to date information and collaboration and notification tools are built right into the workflow.
People, Roles and Permissions
With activeCollab, there’s no limit to the number of users that you can invite.
There are hundreds of startup advice blog posts. Many of them are based on a couple of experiences the respective founders made which are sometimes being presented as universal truth applicable to every startup. What frequently is missing is the context of the writer. So here’s my context: I’m an entrepreneur, I established a single successful (aka profitable) software boutique with my brother before we started to work on Usersnap (a B2B SaaS product), and we failed with another business idea. I’m older than the average startup founders and I did not drop out of university. I’m living in Austria, and I prefer the term “starting a business” instead of “running a startup”.
Disclosing this background, I’d like to share 3 observations I made in the last months.
Thoughts about finding Advisors
Limited life experiences + Over-generalization = Advice
Paul Buchheit, Founder of FriendFeed and creator of Gmail
I’m amazed how many people show the self-confidence to call themselves startup-advisors. At some point, I even got the impression that some failed startup entrepreneurs believe they’ll be able to advise other startups with a rationale that a set of experienced mistakes empowers them to guide fellow startups.
To me, that’s a misconceived plan B. Whereas I strongly believe that sharing failure with other entrepreneurs is very valuable I don’t think this is what advising is about.
At Usersnap, we have over 20 (summed up) years of experience in well organized web development. We figured that track record allows us to call out the good, bad and the ugly in the industry. Now, we don’t like to focus on the negative, but just this once we’ll sum up the bad, as the logical follow-up on our post on best practices in web development.
1. Mails with 20 bullet points
Mails with 20 bullet points, listing bugs, feature request and what not, are as much a commodity as a problem. Often they lead to accusations and “why didn’t you fix $XY, as I pointed out five weeks ago?”-s. In case your head of development is not able to drill these monologues down to workable tickets, chances are you forget things. Instead of muttering all kinds of things your mother didn’t teach you, try and educate your clients or managers how to use a bug tracker or project management tool.* That way you both save time sending countless lengthy emails, and they’ll have a better view of what you’re currently working on.
2. CC’ing the whole team
CC’ing all means: you have no idea who can solve this task. Which is bad in itself. If you start doing this, potentially no one will answer or feel responsible. Plus: reading all those mails will kill a lot of precious time for those who are not into it. Find out who is responsible and address that person only.
As someone making a living in the startup world, one can not have missed the rise of A/B tests, greatly boosted by Eric Ries’ book The Lean Startup. But what is this A/B testing all about? And how do you make sure you get a data-driven approach to product development right for your website or web application?
What is A/B testing?
A/B testing requires to have two different versions of a page, one being your current version, and the other is the version you want to change the page to. Every A/B experiment starts with a little hypothesis. For instance: in order to drive more traffic towards our signup page we need a friendly green button, instead of the blue one we have currently. To research and justify your changes, you route half your visitors to the first page and half to the second. Next, you monitor how many of the visitors perform the desired action (like sign up for your service) on each page, and you calculate the conversion rate for the old and new page. The page with the highest conversion rate is probably the one you should use.
Adrian Smith is a self-employed software architecture and performance consultant currently working on a platform for HR departments that implements quite a few special features. Adrian decided to use Usersnap for this project, to gather specific feedback from his client during the development process.
“We’re using Usersnap on our dev server as the site isn’t live yet. It helps my client to point out and describe what he’d like to see improved. I like this way of receiving feedback. He can highlight areas of the screen etc., i.e. he can really visually say what’s wrong. Which is of course way better than writing an email following the storyline ‘on the third navigation point, the second area, the 3rd word is in a strange position’!”
Adrian’s core usage is within his development team. Screenshots get delivered to his inbox, where he processes them and divides them into tasks in his project management tool, Liquid Planner.
At Usersnap, we have over 20 (summed up) years of experience in well organized web development. We figured that track record allows us to call out the good, the bad and the ugly in the industry. Let’s start with the positive stuff.
1. Use a bug tracker
The inbox of a Head of Development tends to fill up over the day with feature requests, bug reports and snippets of user feedback. Sometimes you’ll even receive emails with a whole bullet point list (if you’re lucky) of requirements, pain points and random ideas. While it’s great that people take the time to give – at times very extended – feedback, it’s not really useful as is.
Using a bug tracker / project management solution like Basecamp or Trac you can reorder tickets and nothing gets lost, as tasks are only closed when they are done. Set a milestone, add keywords (so your co-workers can find your ticket easily), add a priority level and make sure to cc the person in charge of ‘fixing it’. Even if that’s yours truly. In the description, try to provide a user story. And make sure your summary is descriptive, you can use humor for your commit messages if you really have to (i.e.: when it’s done), but you’ll want your ticket to be clear.
2. Take responsibility
Be precise and targeted. You should know who can do what and who is available for an additional task. When in real doubt about who’s responsible, you can do a CC. But make sure to remove all others from the CC, as soon as you found the right person to assign the ticket to.
Trac is a bug tracking system for software development projects. Tracs mission is to help developers writing great software while staying out of the way and should as such impose as little as possible on a team’s established development process. Its timeline shows all current and past project events in order, creating an overview of projects and their progress, and a roadmap lists the upcoming milestones. Identifying bugs and enriching tickets with annotated screenshots with crucial meta-information, that is where the Usersnap integration comes in!
Sign up for your 15-days free trial, or log in to your Usersnap account, and edit the settings for your website. To use the Trac integration, you need to enable the xmlrpc-plugin. Download it from XML RPC-Plugin, copy the egg inside your plugins-directory or install it system wide. You need to enable it by adding tracrpc.*
In a series of blog posts, we’ll discuss web design’s best practices when it comes to usability, responsiveness and accessibility. We care about great design and we’d love to show you that a little CSS love goes a long way. In this post I’ll look at the Twitter search form, to replicate its elegant design.
Recreating the Twitter search form
Now Twitter wraps it’s elements in a whole lot of
spans. I’ll drill it down to the input-element and button, to keep things accessible. Using only HTML, our search form looks a bit ‘boxy’.
In a series of blog posts, we’ll discuss web design’s best practices when it comes to usability, responsiveness and accessibility. We care about great design and we’d love to show you that a little CSS love goes a long way. In this post I’ll look at the Gmail send button, to replicate its clear blue design for your actions.
I went ahead and replicated the necessary HTML and CSS and saved it on Codepen for you to play around with:
Following the responsive design approach for your website, at one point you’ll need to think about what to do with your navigation element(s). Since responsive web-design became a ‘thing’ a few patterns have developed on how to deal with site navigation. As the digital real estate is limited on smartphones, also the navigation concept of websites and web-applications needs to be redefined. How to make your site navigation responsive? Let’s take a look at some popular sites to illustrate the benefits and drawbacks of their solution to the navigation problem on mobile devices.