Recently on the recommendation of an acquaintance, I signed up for an account over at Teambox to organize some projects. Having been a long time user of Basecamp, and a trial user of many other online project management platforms, I was quite impressed by the simple elegance of Teambox.
Why SaaS companies need Retina
In 2010, Apple raised the bar, or rather the pixel density, for what our eyes perceive as “Quality.” From that day on, iOS developers had no option but to quickly adopt Retina graphics, or face customer perception that their app was inferior. While what you spent months building prior to the iPhone 4 launch might be a revolutionary, magic app, if it looks fuzzy to me, my first impression is ruined and it can’t possibly be good.
Fast forward a couple years to 2012 and the new MacBook Pro with Retina. Apple has spoiled our eyes and raised our expectations about what to expect in a laptop screen. Spend a few minutes on a new rMBP, and going back to a “normal” laptop screen is quite an unpleasant experience.
MacOS applications are undergoing a transformation, similar to that experienced by iOS apps: Microsoft Office, Adobe Photoshop gaining Retina support in December 2012. No new MacOS app would be caught dead without Retina support.
Yet somehow websites seem slow to adopt the new standard. It’s as if most web designers want Safari, Chrome, or Firefox to do the heavy lifting. Fact is, when you load a website unoptimized for Retina on a new MacBook Pro with Retina, you see a fuzzy mess in the middle of your an incredibly sharp Retina browser.
People might not really care if the banner looks a bit fuzzy when they’re looking at a food blog, but if you expect user to pay for your service, or your income depends on eyeballs on your site, then it’s time to raise the pixel count.
Looking around the Internet today, companies like Facebook, GoPro, Stripe (awesome payment processor) and of course Pay4Bugs have began to make the necessary asset upgrades to support Retina graphics, while more old-school (but still tech) companies like Internap now sport a fuzzy look.
Some might say that the number of users on the new MacBook Pro is tiny, and probably not worth the effort. If you look at the populace as a whole, it might be true. However, take a look inside any tech company like Google and you’ll spot more MacBook Pros than on display at an Apple store. Even in non-tech companies, many decision makers wield a combination of iPhone 5, New iPad, and the top of the line rMBP. Trying to sell a service to them with fuzzy graphics is like trying to sell an unwashed new car in a showroom. Don’t believe me? (you might not if you’re not on Retina yourself) Go to your local Apple store and try it out.
In the coming months, more Macs and PCs are going to support Retina graphics. Is your site retina-ready? If you need to test your Retina-website, we can help you with that on Pay4Bugs too. Got a Retina conversion story you want to share, chime in below with some screen shots and we’ll link to your before and after shots.
Isn’t it wonderful when tech companies work with each other? This is synergy without any of the boardroom bureaucracy, just simple Ruby-on-Ruby lovin’
As some of you may know, Pay4Bugs was first conceived to fulfill an internal need. We needed to debug, and wanted a good platform to do so. Since then, we’ve developed Mobile Software Testing (we wrote apps), and integration with Basecamp (we love 37Signals). When there’s a need that can be resolved with some code, we do it.
Of course we can’t always be building just for ourselves. A client of Pay4Bugs recently requested integration with Lighthouse. So what are they? From the Entp website (the fine folks behind Lighthouse), Lighthouse is described as “a hosted ticket/issue tracking application that we built to handle our own product development in the most simple workflow environment we thought possible.” Sounds good to us.
So after a few days of coding, we’ve completed integration with Lighthouse. Now when you approve a bug, Pay4Bugs will automatically send the information over to Lighthouse via the API. Find bugs here, track it there. Synergy.
Know any other software that you want to see us integrate with? Let us know via the comments below.
For people who use 37Signal’s Basecamp to manage their projects, and use Pay4Bugs to find bugs, we just upgraded our API integration to make the interaction between the two sites more seamless.
As we described previously, when you enter your Basecamp API key into your Pay4Bugs profile, every time you approve a bug, it’ll enter a to-do list item automatically in your Basecamp project. However we didn’t think that was enough, since the integration was only one way.
Now when you complete a to-do item in Basecamp, we send the information back to your bug list on Pay4Bugs. This way as soon as a bug is resolved, it’ll appear as “fixed”, making it easier for testers as they approach your project.
Got any productivity APIs that you think we should connect to? Chime in with the comments section below!
Everything looks the same, but as of a week ago, Pay4Bugs is now running on Rails 3 and Ruby 1.9. The past couple months, we’ve been porting the code base over and fixing bugs. Thanks as always to Pay4Bugs Testers for keeping us on our toes and quickly pointing out any bugs that slipped through our internal testing.
Now that we’ve got the codebase up to date, Pay4Bugs customers can look forward to a number of new client requested features and refinements on an accelerated schedule.
Last Friday, we launched a new email digest feature for customers. By default, clients will no longer receive an email for every new bug. We realize how annoying this was. Instead, clients will receive daily summary emails on days when new bugs are submitted and weekly email summaries otherwise. Miss the per bug emails? You can turn them back on by clicking My Info.
We’re huge fans products by 37Signals, which helps small businesses and enterprises organize projects and contacts in “the cloud” with their various web applications. Their flagship product is Basecamp, the project management software that we use internally and have recommended to many of our friends and clients.
The fact that Ruby on Rails was actually a framework extracted from their work on Basecamp makes them that much cooler. Need more convincing? the creator of Ruby on Rails Heinemeier Hansson commissioned his own special edition Italian sports car , but I digress…
Therefore we’re thrilled to announce that Pay4Bugs has now integrated with the Basecamp API, creating the bug squishing tag team that’s designed to deliver results.
Here’s how it works it a nutshell:
- Developers create new software products that could benefit from real life testing and debugging. A Pay4Bugs project is created with a bounty. In the project settings, connect to Basecamp using the Basecamp API.
- Testers around the world step up to the challenge, and submit bug reports to the developer.
- The project manager vet the incoming bug reports. Legitimate bugs are approved, and the information is automatically sent into your Basecamp project.
- Track your open bugs via the awesomely simple “To-do” lists in Basecamp, and watch the developers squash bugs with epic efficiency.
Software bugs, meet your worse nightmare.
Basecamp is a project management platform from 37Signals. Pay4Bugs clients can integrate their Pay4Bugs projects with Basecamp by entering their Basecamp API Token.
To find your token, login to your Basecamp account, then click on “My Info” on the top right hand corner. Scroll down past the contact information to a box labeled “Authentication tokens.” Click on the “Show your tokens” link and grab your unique API Token, which permits Pay4Bugs to send bug reports directly to your project t0-do list.
Hong Kong - October 2011 – Appartisan Limited announced today that its Pay4Bugs Crowdsourced Software Testing product has been selected as a Finalist for Red Herring’s Top 100 Asia award, a prestigious list honoring the year’s most promising private technology ventures from the Asian business region.
The Red Herring editorial team selected the most innovative companies from a pool of hundreds from across Asia. The nominees are evaluated on both quantitative and qualitative criteria, such as financial performance, technology innovation, quality of management, execution of strategy, and integration into their respective industries.
This unique assessment of potential is complemented by a review of the actual track record and standing of a company, which allows Red Herring to see past the “buzz” and make the list an valuable instrument for discovering and advocating the greatest business opportunities in the industry.
“This year was very rewarding,” said Alex Vieux, publisher and Chairman of Red Herring. “The global economic situation has abated and there are many great companies producing really innovative and amazing products. We had a very difficult time narrowing the pool and selecting the finalists. Pay4Bugs shows great promise therefore deserves to be among the Finalists. Now we’re faced with the difficult task of selecting the Top 100 winners of Red Herring Asia. We know that the 2011 crop will grow into some amazing companies that are sure to make an impact.”
Finalists for the 2011 edition of the Red Herring 100 Asia award are selected based upon their technological innovation, management strength, market size, investor record, customer acquisition, and financial health. During the several months leading up to the announcement, hundreds of companies in the telecommunications, security, Web 2.0, software, hardware, biotech, mobile and other industries completed their submissions to qualify for the award.
As our tester community continues to grow, we are making efforts to improve the overall quality of the platform, and reward the testers that file detailed, quality bug reports.
Today we’re thrilled to launch the Pay4Bugs Rep System, a reputation engine that takes your testing activity on Pay4Bugs, and through an algorithm determines a numeric rep score. Testers are rewarded when their bug reports are approved by clients, and the score is lowered when their bug reports are rejected.
In the first phase, we’re providing the Rep score to iOS Mobile Testing clients, to help them decide to should be admitted to their testing program. Going forward, we’ll make changes so that testers with higher Rep scores will be given more unique testing opportunities, with higher bounties. There are a lot more we plan to do with Pay4Bugs Rep, so stay tuned for more in the coming weeks!
A few days ago, I wrote a piece on why you should build native apps for Android devices, just to meet the expectations of Android users. In the article, I presented many arguments on why building native apps, natively without using one-size-fits-all SDKs will ultimately benefits your app. Today though, I present an inherent annoyance about developing for, or supporting Android devices with a real life example I encountered myself.
About a year ago, Apple’s management team brought up the growing issue of Android fragmentation during a conference call, drawing the ire of many Android supporters. Many Android developers were quick to point out that Apple also has a fragmented ecosystem consisting of the iPhone (4 versions), iPod Touch (4 versions), and iPads, along with various different versions of iOS. It was believed that Android would fare no worse.
The problem is, handset manufacturers and carriers actually sometimes think they know better than Google. (Whereas nobody knows better than Apple)
If manufacturers and carriers all followed Google’s specifications on Android, then there would not be an issue. The PC market worked this way for decades. However the open nature of Android OS allows handset manufacturers to tinker the device, for better or worse. Usually worse.
For example, a few weeks ago a Pay4Bugs client was presented with a bug report on its VPN service, claiming he could not connect with his Android powered phone. Worried that the service might have issues, the the VPN connection was tested repeatedly via PC, Mac, iOS, and finally Android. Everything worked.
Digger further into the issue, the Motorola Droid forums had the explanation. The support for VPN with passwords was REMOVED from the original Motorola Droid, running Android 2.1. Why Motorola (or perhaps Verizon) thought this was necessary we’ll probably never know, but needless to say the reporter of the bug (and VPN customer) was quite disappointed, and even angry for his handicapped device.
That was but one small example of fragmentation, feel free to share yours in the comments below. With Google’s recent proposed purchase of Motorola, hopefully future handsets will stick with the rules as defined by Google’s Ice Cream Sandwich. All Google have to do now, is make sure Verizon and AT&T doesn’t boss them around, because for the most part, I still believe you know better.
btw, if anyone knows how to get VPN to work on Droid, please also let us know below. I’ve pretty much given up on solving that issue.