8 ms·

Show HN: Helium - Simple web automation

48 points by mherrmann 13y ago

Hi everyone, I'm working for a startup called BugFree Software and would love to hear your feedback on a new product we are launching today. Helium is a library that wraps around Selenium to simplify web automation. It does away with many of the technicalities involved with web scripting. For example: Here is a Selenium script. Can you guess what it does? >>> ff = Firefox() ... >>> text_area = ff.find_element_by_id("u_0_1q") >>> text_area.send_keys("Hello World!") >>> button = ff.find_element_by_class_name("_42g-") >>> button.click() Here is the same script rewritten using Helium: >>> start_firefox() ... >>> write("Hello World!", into="Update Status") >>> click("Post") Can you now guess what it does? That's right; It updates your Facebook status. In an extended comparison that we were invited to write for the December issue of Professional Tester (professionaltester.com), we found that an example script automating Gmail took 66% fewer lines of code and 75% less effort using Helium than with Selenium alone. You can find more information and download Helium from http://heliumhq.com. Any feedback would be highly appreciated. Hoping to hear your thoughts and comments, Michael Herrmann heliumhq.com

deleted 13y ago
[deleted]
- deleted 13y ago
  [deleted]
mapleoin 13y ago
Closed source development tools with a EULA? What is this? 1995?
- Taurenking 13y ago
  Not everyone can enjoy a part time job or an enviroment in where he can seriously develop side projects, and still have enough money to sustain itself...
- mherrmann 13y ago
  We quit our daytime jobs to work on this project and have to live off something... Maybe you have a suggestion as to what we could do to allow us to sustain our development in another way?
  - moconnor 13y ago
    This is a really interesting problem. There's the expectation - and desire - for all software, particularly development tools, to be open source. This seems to make it harder for independent developers to devote time to creating great tools. Is the future of software tools in the side-effects of teams at large organizations open sourcing things they needed to solve their own problems?
    - mherrmann 13y ago
      I agree that it's interesting and that it is a problem. You could see from mapleoin's comment that closed source software is not looked at favorably. I can see why, but as I said if we want to sustain full-time development of this project, we need an income. One approach that's often used with open source projects is to develop the software for free and then charge for consulting. But, with a tool such as Helium that aims to be extremely simple, I don't see much room for such services. I'd be extremely curious to hear if anybody has an answer to this problem.
      - deleted 13y ago
        [deleted]
      - hyp0 13y ago
        First off, excellent idea. It seems simple and straightforward to automate web site interaction, especially for those lacking APIs (e.g. my stoneage bank, to check for telegraphic transfer payments). But I'm torn. On the one hand, I support developers getting paid for creating tools/libraries (instead of working on in-house software; or consumer/business startups). I think it's better for the world. It's also how I've supported myself for the last 10 years. On the other hand, I don't like your email-wall etc. As I see it, you need to serve two markets: the businesses that will pay for your software; and everyone else, who won't pay, but will promote it word-of-mouth/google juice, through blog posts, stackoverflow answers, reddit/HN posts/comments etc etc etc (this is incredibly helpful for getting sales). Thus, you need to serve both, and make it both easy to buy, and easy to not buy. 1. Your email-wall is one solution. People can still get it free, they just don't like. I think it will fail (but it might work, who knows?) 2. Another way is two versions: free/community/demo and paid. Find features that matters a lot to businesses (or sounds like it), and doesn't matter to everyone else. Quotas are another way, although hard to enforce in a library (easy in a webapp), but also consider that legit businesses prefer buying over cracking. (e.g. pkzip got pirated like crazy, but the guy also made money). 3. A way to do open source is "dual-licensing": GPL + commercial. The GPL forbids closed-source distribution, so you license it to people who want to distribute it. The problem with this (I did it) is long sales-cycles, because there's no urgency for people to buy, they already have it. (they do eventually pay, it just takes a long time). Ghostscript does something similar. But your big problem is more subtle: you have a cool idea that is truly valuable to businesses - but it's easy to implement. I think most coders here could hack a barely-working prototype within 2 hours. All it takes is one of them to publish it on github, and keep working on it for 6 months, and you're finished. It's not because theirs is better than yours - but because they will get ALL the word-of-mouth and google-juice. Thus, you need to serve both markets. This denies oxygen to the copy-cats - why would anyone bother with that half-assed knock-off, when they can get the real thing from you? Even if someone starts a clone, it will languish without any interest or feedback. People also like to reward originators (provided it doesn't actually cost them anything...). Another thing you can do is implement difficult features - from skimming your site, it all looks pretty easy... but if you find some obstacle that seems to kill how it should work, that's a GREAT thing. Solve it, and you have a barrier (this is what happened for me). Or as Joel said, "where there's muck there's brass". But the most important thing for your long-term success is to realize the situation is dynamic. You have to keep improving constantly (this often means discovering new ways to improve, even when it seems there aren't any). Even if someone copies, you still have the latest and greatest. Thus, you can measure your barrier in time - how long before they catch up? Even if it's only 6 months - or even 1 month - provided yours is always significantly better, everyone (businesses and others) will prefer it. There's also some lag, that it takes for word to get out of a competitor, to build word-of-mouth/google-juice, and to convince pragmatists that it really is credible. So this "market" lead also gives you some time (probably only a few months though). Note: even when hackers are no longer excited, businesses will still be interested - because they don't buy cool technology, they buy solutions to their problems. They don't care how sexy it is, they care if it works, and that's it. So don't be discouraged when you are no longer hot. Finally, to address your comment directly: I agree it's a problem, for libraries especially. I think open-source + consulting is a terrible idea (unless you're a consultant - then it's fantastic publicity. But conflict with making it easy to use, so it doesn't need a consultant...). Looking at wildly successful developer tools, they seem to be desktop tools: IDEs (JetBrains on the frontpage now); xmlspy and a bunch of xml tools. I don't know why this is (Maybe it feels like non-code to programmers, unlike a library? Maybe because it's more work, and needs GUI-skills/interest?) I'm intrigued by the idea of "service components": library-like functionality, used through web-APIs. (In contrast, most current web-APIs access data and/or business service, not a computational service). It would sit in the cloud, next to their web-app, so it's fast - but they don't have the source, and can only access it to via the web-API. Note that libraries naturally are accessed through an API - this is just on a different machine, like a DB often is (you probably want to config the query, then run it, to minimize network traffic). Then you can do quota restrictions, like any other web-app. --- One thing though: if it doesn't work, please try a few other strategies before giving up. You have a valuable idea there.
- oblio 13y ago
  Whoa there you FOSS commie! (just kidding, I know mapleoin)
Taurenking 13y ago
this seems an iteresting project...how does the click() function work? Is it possible to automate other actions beside the ones in the example?
- mherrmann 13y ago
  Sure, you can find other actions on the docs page, http://heliumhq.com/docs/api_documentation http://heliumhq.com/docs/api_documentation
lfx 13y ago
Hey, looks nice. Wonder how lib is detecting inputs by "user-visible labels". Looks by html structure, or uses some "magic" methods?
- mherrmann 13y ago
  Thanks! For now, it looks by (x, y) position on the web page.
  - hpaavola 13y ago
    Position of what? Why? Given following markup: <label for="foobar">Lorem ipsum</label> <input id="foobar"> Does write('omg', 'Lorem ipsum') write into #foobar? Just to clarify since position of those two elements might not be similar at all.
    - mherrmann 13y ago
      In that case, it will write into #foobar because it is smart enough to understand that <input/>s can be written to, and not labels. It works in a way that is very similar to us humans: If someone tells us to "write 'Michael' into the 'First Name' field", we look for the text "First Name" and then to the right and bottom of this text if there is a field that can be written to. So, position in this case is position on the page in (x, y) coordinates. If there are multiple occurrences (eg. two "First Name" fields) then Helium scans the page top-to-bottom, and closest to the element you last interacted with. Like a human would normally also do.
hipsters_unite 13y ago
A question (not meant facetiously) but what's the benefit of this over say, Capybara/webrat, which already has the click and fill_in human readable methods? The block of example code looks pretty much like an RSpec/Capybara spec, is all.
- mherrmann 13y ago
  Several things. I claim it's still more high level than Capybara. And it's available for languages other than Ruby. Right now, you can download it for Python. But we'll also release bindings for (hopefully all) languages supported by Selenium.
  - hipsters_unite 13y ago
    Okay, thanks. Is this aimed at developers then, rather than say the product team?
    - mherrmann 13y ago
      I would say it's aimed at anyone willing to do light programming / scripting. I don't think a particular role within a company precludes this. (Sorry for the late reply by the way, I lost track among all the comments here.)
deleted 13y ago
[deleted]
briancray 13y ago
I would suggest also allowing CSS selectors as a fallback. Text changes often whereas a selector will change less often, producing a more reliable point of interaction. I would also suggest you put a screencast of a hello world. With many people new to testing using headless webkit, they may have the wrong perception of how selenium tests are run. Additionally what may not be obvious to people used to javascript-based headless webkit tests is that Selenium/Helium tests are written in python. Might want to clarify that as well. Good luck!
- mherrmann 13y ago
  Hi, thanks for the suggestions! I'll discuss them with my colleagues. CSS selectors are supported, because Helium is fully compatible with Selenium. Eg.: You can say click(driver.find_element_by_css_class('btn')), where click(...) is a Helium command and driver.find_element_by_css_class(...) is from Selenium. Helium and Selenium are 100% interoperable. Thanks again! :-)
fygwtclub 13y ago
I overheard "Selenium" is the cure for "Mercury" poisoning. What's behind the name "Helium". Just curious. I would love to use "Helium" soon. All the best for your work.
- mherrmann 13y ago
  The answer is simple: Helium is lighter than Selenium! ;-) You can already use it today by downloading from http://heliumhq.com/download http://heliumhq.com/download. Thanks for the kind words!
  - deleted 13y ago
    [deleted]
devspade 13y ago
Trying to figure out what this gives me that Selenium doesn't? If I already have a large code base using Selenium why should I switch?
- mherrmann 13y ago
  Good question. It can't do anything that Selenium can't, but it's a lot easier to work with. It's like developing in Assembler vs developing in C: Both are equally powerful in what they can achieve, but the former is much more technical to use than the latter. The analogy extends further: We were invited to write an article about Helium in the December issue of Professional Tester (professionaltester.com) in which we compared automating Gmail with Helium vs pure Selenium. The code with Helium was 66% shorter, but ran on average 26% slower than an (optimized) Selenium script. You can find a thorough analysis covering the differences between Helium and Selenium here: http://heliumhq.com/AutomatingGmailWithHelium.pdf http://heliumhq.com/AutomatingGmailWithHelium.pdf
  - devspade 13y ago
    Interesting. We have a ton of work put into Selenium already so switching costs would be rather high for our team. But probably worth keeping an eye on this project. You're going to have some big obstacles to overcome trying to get people to pay for this versus using Selenium.
    - mherrmann 13y ago
      Just would like to comment that you wouldn't have to "switch" completely. Helium is fully interoperable with Selenium, that is, you can freely mix calls to Helium to calls with Selenium. So in your case, you could add the Helium library to your project and when you extend or maintain it, at every step, choose whether you want to perform a particular step with Helium or Selenium.
oblio 13y ago
I hope you succeed with your project, but sorry, I feel that your pricing is batshit insane, pardon my French. $200 per year subscription for 1 machine for the basic license with support only for the installation, basically. And probably bugfixes, I'm guessing. If for whatever reason I'd like to create a 3-4-5 VM test farm I'd have to pay $600-$800-$1000 per year. And, again, subscription. If I don't pay after one year I cannot use this anymore. Combined with the closed source factor, I really don't like it, sorry.
- mherrmann 13y ago
  Thank you for the honest feedback and the good wishes. Here's why we think our subscription model makes sense: In our evaluation (heliumhq.com/AutomatingGmailWithHelium.pdf), developing a script with Helium took 75% less effort (man-days) and 66% less code than a script written in pure Selenium. The average developer salary in the US in 2010 was $90k a year(http://money.usnews.com/careers/best-jobs/software-developer/salary http://money.usnews.com/careers/best-jobs/software-developer...). Say this developer works 260 days a year, so makes roughly $350 a day. If it doesn't take him 75%, but only 25% less effort to write and maintain some web automation code, then each day of him working with Helium saves the company $87.5. This means that after about 11 working days, using Helium will have paid off, leaving potentially 249 more days in the year during which to reap Helium's benefits.
  - hyp0 13y ago
    Most developers aren't scripting web interaction fulltime. This gives you a target: in which businesses are they doing lots of it? Have some copy on your website that speaks to the managers of those specific businesses - since they are the ones who decide and pay for it. The scenario plays out: developer is sick of testing, hears about Helium, tries it, it works great, he badgers his boss to buy it, boss looks at website, says this is fantastic, let's buy 100, he goes to the next tier of management for approval, and has all the answers for their concerns.
    - mherrmann 13y ago
      Very valid points. Especially the barrier that the developer is not the one who makes the purchase decision is one we have already encountered in a previous product.
adambenayoun 13y ago
@mherrmann - There are various ways you could monetize Helium and be open source - here are a few ideas. All of them assume that you will be open sourcing your code. The reason for open sourcing this would be to basically achieve wider adoption which will in turn allow you to monetize 5-10% of your audience (Enterprise customer for example). 1. Open Core Licensing - You could create a community edition and an enterprise edition. The community edition would be completely open source and available for free. While you work on the community edition you could identify the 5% of additional features that certain customers (Enterprise for example) would pay for. I think this is a pretty fair way to balance between giving away a free product and creating an enterprise/professional edition where you'd charge a license fee from customers who would have the ability to pay for it. One of the challenges with this model is to make sure you find the right balance between the community and enterprise edition since some people will be upset that certain feature aren't released in the community but make it into the enterprise edition. 2. SaaS - If you open source it and gain widespread adoption - at some point it might makes sense to create a service that allow users to run these tests on the cloud and create a complete suite of features around it. Many developers are happy to pay a service fee for using an hosted version of the open source software that allow them to not deal with hosting, patching and servicing that software. If you do that releasing it under the AGPL will give you a competitive advantage since if someone would like to create a hosted service and improve the open source software, they would have to release all changes to the community (or license a commercial version from you), however if you decide to add some secret sauce in the hosted solution, you ARE NOT required to release it to the community since you could license it under a commercial license to yourself. 3. Offer professional services, support and training - Once developers will start using this in their workflow and start being dependent on that software, they will want the peace of mind of paying for support (or the ability to contact you and ask questions). You could have various SLA of support. For examples: Community edition (FREE) would have access to community forum where users could help each other - at first you'd seed that forum with your own support to kickstart the community. Then you could offer several level of support, from email (9-5 or 24/7) to phone support to various customers. Additionally you could offer up to a certain amount of training or consulting to write custom tests for customers who will need your help integrating this into their workflow. Most often people will opt for paying for a basic license even if the software is free just so they have someone to nag and talk to if things go south. There are more ways that you could monetize open source - if you found this reply useful and would like to learn more - feel free to reach out to adam (at) binpress (dot) com - I am the co-founder at http://www.binpress.com http://www.binpress.com - the marketplace for commercial open source - we're on a mission to help developers monetize their open source projects.
Edmond 13y ago
I read through the comments and see you are catching a lot of flack for being closed source and daring to charge. My advice, do what you think makes sense for your company. You seem to have already done some cursory market research and I am guessing based on that you've decided on your current course of action...stick with it unless you have a good reason to change direction. Feedback is definitely important and useful but take it with a grain of salt. The HN crowd is a rather biased one and doesn't really reflect the broader dev world. Maybe try attending some dev meetups where you are likely to get a more diverse opinion. You've already quit your day job to do this, unless one of these folks is going to be paying your rent, you should absolutely focus on monetizing your product. In terms of the open vs closed source issue, I do agree that dev products should make their source code available, but that is only so it is easy to fix problems and address security concerns. You don't have to make it "open source", as in: allow people to freely alter and redistribute. I use this same approach with my company's product, which is also a dev tool (see my profile if you want to check it out).
- mherrmann 13y ago
  Thanks for the realistic and encouraging words. I was beginning to feel like a bad human being for charging for my work ;-) So you give the source code for your product to your customers, once they have bought it?
  - Edmond 13y ago
    Yes most of the source code is included with the product. There is a small portion of it reserved for commercial entities, mainly the source code for our middleware, but even that will be included in the future.
duked 13y ago
Hi, I like the idea and I used watir [0] in the best to do a lot of automation but I fail to see what's different with Helium. Can you please tell me what are the differences besides python vs ruby ? [o]http://watir.com/ http://watir.com/
teh_klev 13y ago
First of all let me say that I have no problem with paying for software, even closed source or otherwise. I already pay a chunk of personal money for JetBrains tools and stuff from RedGate to let me get on and do my job more efficiently, and my company does the same. However your license condition: "If you want to run Helium on another machine then you must first remove it from the computer you were using it on previously." I work across a few different machines - work PC, other work PC and PC in lounge at home, VM's etc. This license condition just isn't practical or financially viable for solo developers or small dev shops who work like this. Do you actively check for multiple installs under the same license i.e. with a registration server? Altova XML Spy used to do this and it quickly got binned after the first year's license came up for renewal because they messed up the licensing records (PC crashed, couldn't de-register in-use licenses etc, hassle, hassle hassle) and we had developers working in VM's for a bunch of different projects all at once. Yes we could defeat the LAN sniffing it did to find out if two copies of the XML Spy were running with the same license, but it was too much effort and we resented having to do this - despite each dev being properly licensed. Vendors such as JetBrains and RedGate license the software to me/company for use by a single developer/user, I don't have restrictions such as "you must first remove it from the computer you were using it on previously". I/we are happy to buy licenses for each developer on our team "using" the software, but not for each and every VM or dev env a single developer is working in. As such I haven't bothered to let my colleagues know about this tool which sounds pretty cool, nor have I tried to download it (forcing me to part with contact details to try something really puts me off). I understand that you have to eat and pay the rent, but even for a company like ours, that has a fairly generous budget for development tools, this type of "per-installed machine" license is considered hostile for the type of tool being sold. I'm generally not a negative person when it comes to "Show HN" and I truly appreciate the efforts people put into their projects whether it be for a paid-for product or showing off some hacks or tricks, but your license....it frustrates me.
- mherrmann 13y ago
  I see. I'm very sorry to hear that you are so frustrated with the licensing scheme. We should also offer "floating" licenses which are not tied to a particular machine. Would that be OK for your needs?
mherrmann 13y ago
We have now added a Social License to our Purchase page (http://heliumhq.com/purchase http://heliumhq.com/purchase). It gives everyone who tweets about Helium a free license!
- resu 13y ago
  That's an excellent idea :)

48 points by mherrmann 13y ago

deleted 13y ago

[deleted]

deleted 13y ago
[deleted]

mapleoin 13y ago

Closed source development tools with a EULA? What is this? 1995?

Taurenking 13y ago
Not everyone can enjoy a part time job or an enviroment in where he can seriously develop side projects, and still have enough money to sustain itself...
mherrmann 13y ago
We quit our daytime jobs to work on this project and have to live off something... Maybe you have a suggestion as to what we could do to allow us to sustain our development in another way?
- moconnor 13y ago
  This is a really interesting problem. There's the expectation - and desire - for all software, particularly development tools, to be open source. This seems to make it harder for independent developers to devote time to creating great tools. Is the future of software tools in the side-effects of teams at large organizations open sourcing things they needed to solve their own problems?
  - mherrmann 13y ago
    I agree that it's interesting and that it is a problem. You could see from mapleoin's comment that closed source software is not looked at favorably. I can see why, but as I said if we want to sustain full-time development of this project, we need an income. One approach that's often used with open source projects is to develop the software for free and then charge for consulting. But, with a tool such as Helium that aims to be extremely simple, I don't see much room for such services. I'd be extremely curious to hear if anybody has an answer to this problem.
    - deleted 13y ago
      [deleted]
    - hyp0 13y ago
      First off, excellent idea. It seems simple and straightforward to automate web site interaction, especially for those lacking APIs (e.g. my stoneage bank, to check for telegraphic transfer payments). But I'm torn. On the one hand, I support developers getting paid for creating tools/libraries (instead of working on in-house software; or consumer/business startups). I think it's better for the world. It's also how I've supported myself for the last 10 years. On the other hand, I don't like your email-wall etc. As I see it, you need to serve two markets: the businesses that will pay for your software; and everyone else, who won't pay, but will promote it word-of-mouth/google juice, through blog posts, stackoverflow answers, reddit/HN posts/comments etc etc etc (this is incredibly helpful for getting sales). Thus, you need to serve both, and make it both easy to buy, and easy to not buy. 1. Your email-wall is one solution. People can still get it free, they just don't like. I think it will fail (but it might work, who knows?) 2. Another way is two versions: free/community/demo and paid. Find features that matters a lot to businesses (or sounds like it), and doesn't matter to everyone else. Quotas are another way, although hard to enforce in a library (easy in a webapp), but also consider that legit businesses prefer buying over cracking. (e.g. pkzip got pirated like crazy, but the guy also made money). 3. A way to do open source is "dual-licensing": GPL + commercial. The GPL forbids closed-source distribution, so you license it to people who want to distribute it. The problem with this (I did it) is long sales-cycles, because there's no urgency for people to buy, they already have it. (they do eventually pay, it just takes a long time). Ghostscript does something similar. But your big problem is more subtle: you have a cool idea that is truly valuable to businesses - but it's easy to implement. I think most coders here could hack a barely-working prototype within 2 hours. All it takes is one of them to publish it on github, and keep working on it for 6 months, and you're finished. It's not because theirs is better than yours - but because they will get ALL the word-of-mouth and google-juice. Thus, you need to serve both markets. This denies oxygen to the copy-cats - why would anyone bother with that half-assed knock-off, when they can get the real thing from you? Even if someone starts a clone, it will languish without any interest or feedback. People also like to reward originators (provided it doesn't actually cost them anything...). Another thing you can do is implement difficult features - from skimming your site, it all looks pretty easy... but if you find some obstacle that seems to kill how it should work, that's a GREAT thing. Solve it, and you have a barrier (this is what happened for me). Or as Joel said, "where there's muck there's brass". But the most important thing for your long-term success is to realize the situation is dynamic. You have to keep improving constantly (this often means discovering new ways to improve, even when it seems there aren't any). Even if someone copies, you still have the latest and greatest. Thus, you can measure your barrier in time - how long before they catch up? Even if it's only 6 months - or even 1 month - provided yours is always significantly better, everyone (businesses and others) will prefer it. There's also some lag, that it takes for word to get out of a competitor, to build word-of-mouth/google-juice, and to convince pragmatists that it really is credible. So this "market" lead also gives you some time (probably only a few months though). Note: even when hackers are no longer excited, businesses will still be interested - because they don't buy cool technology, they buy solutions to their problems. They don't care how sexy it is, they care if it works, and that's it. So don't be discouraged when you are no longer hot. Finally, to address your comment directly: I agree it's a problem, for libraries especially. I think open-source + consulting is a terrible idea (unless you're a consultant - then it's fantastic publicity. But conflict with making it easy to use, so it doesn't need a consultant...). Looking at wildly successful developer tools, they seem to be desktop tools: IDEs (JetBrains on the frontpage now); xmlspy and a bunch of xml tools. I don't know why this is (Maybe it feels like non-code to programmers, unlike a library? Maybe because it's more work, and needs GUI-skills/interest?) I'm intrigued by the idea of "service components": library-like functionality, used through web-APIs. (In contrast, most current web-APIs access data and/or business service, not a computational service). It would sit in the cloud, next to their web-app, so it's fast - but they don't have the source, and can only access it to via the web-API. Note that libraries naturally are accessed through an API - this is just on a different machine, like a DB often is (you probably want to config the query, then run it, to minimize network traffic). Then you can do quota restrictions, like any other web-app. --- One thing though: if it doesn't work, please try a few other strategies before giving up. You have a valuable idea there.
oblio 13y ago
Whoa there you FOSS commie! (just kidding, I know mapleoin)

Taurenking 13y ago

this seems an iteresting project...how does the click() function work? Is it possible to automate other actions beside the ones in the example?

mherrmann 13y ago
Sure, you can find other actions on the docs page, http://heliumhq.com/docs/api_documentation http://heliumhq.com/docs/api_documentation

lfx 13y ago

Hey, looks nice. Wonder how lib is detecting inputs by "user-visible labels". Looks by html structure, or uses some "magic" methods?

mherrmann 13y ago
Thanks! For now, it looks by (x, y) position on the web page.
- hpaavola 13y ago
  Position of what? Why? Given following markup: <label for="foobar">Lorem ipsum</label> <input id="foobar"> Does write('omg', 'Lorem ipsum') write into #foobar? Just to clarify since position of those two elements might not be similar at all.
  - mherrmann 13y ago
    In that case, it will write into #foobar because it is smart enough to understand that <input/>s can be written to, and not labels. It works in a way that is very similar to us humans: If someone tells us to "write 'Michael' into the 'First Name' field", we look for the text "First Name" and then to the right and bottom of this text if there is a field that can be written to. So, position in this case is position on the page in (x, y) coordinates. If there are multiple occurrences (eg. two "First Name" fields) then Helium scans the page top-to-bottom, and closest to the element you last interacted with. Like a human would normally also do.

hipsters_unite 13y ago

A question (not meant facetiously) but what's the benefit of this over say, Capybara/webrat, which already has the click and fill_in human readable methods? The block of example code looks pretty much like an RSpec/Capybara spec, is all.

mherrmann 13y ago
Several things. I claim it's still more high level than Capybara. And it's available for languages other than Ruby. Right now, you can download it for Python. But we'll also release bindings for (hopefully all) languages supported by Selenium.
- hipsters_unite 13y ago
  Okay, thanks. Is this aimed at developers then, rather than say the product team?
  - mherrmann 13y ago
    I would say it's aimed at anyone willing to do light programming / scripting. I don't think a particular role within a company precludes this. (Sorry for the late reply by the way, I lost track among all the comments here.)

deleted 13y ago

[deleted]

briancray 13y ago

I would suggest also allowing CSS selectors as a fallback. Text changes often whereas a selector will change less often, producing a more reliable point of interaction. I would also suggest you put a screencast of a hello world. With many people new to testing using headless webkit, they may have the wrong perception of how selenium tests are run. Additionally what may not be obvious to people used to javascript-based headless webkit tests is that Selenium/Helium tests are written in python. Might want to clarify that as well. Good luck!

mherrmann 13y ago
Hi, thanks for the suggestions! I'll discuss them with my colleagues. CSS selectors are supported, because Helium is fully compatible with Selenium. Eg.: You can say click(driver.find_element_by_css_class('btn')), where click(...) is a Helium command and driver.find_element_by_css_class(...) is from Selenium. Helium and Selenium are 100% interoperable. Thanks again! :-)

fygwtclub 13y ago

I overheard "Selenium" is the cure for "Mercury" poisoning. What's behind the name "Helium". Just curious. I would love to use "Helium" soon. All the best for your work.

mherrmann 13y ago
The answer is simple: Helium is lighter than Selenium! ;-) You can already use it today by downloading from http://heliumhq.com/download http://heliumhq.com/download. Thanks for the kind words!
- deleted 13y ago
  [deleted]

devspade 13y ago

Trying to figure out what this gives me that Selenium doesn't? If I already have a large code base using Selenium why should I switch?

mherrmann 13y ago
Good question. It can't do anything that Selenium can't, but it's a lot easier to work with. It's like developing in Assembler vs developing in C: Both are equally powerful in what they can achieve, but the former is much more technical to use than the latter. The analogy extends further: We were invited to write an article about Helium in the December issue of Professional Tester (professionaltester.com) in which we compared automating Gmail with Helium vs pure Selenium. The code with Helium was 66% shorter, but ran on average 26% slower than an (optimized) Selenium script. You can find a thorough analysis covering the differences between Helium and Selenium here: http://heliumhq.com/AutomatingGmailWithHelium.pdf http://heliumhq.com/AutomatingGmailWithHelium.pdf
- devspade 13y ago
  Interesting. We have a ton of work put into Selenium already so switching costs would be rather high for our team. But probably worth keeping an eye on this project. You're going to have some big obstacles to overcome trying to get people to pay for this versus using Selenium.
  - mherrmann 13y ago
    Just would like to comment that you wouldn't have to "switch" completely. Helium is fully interoperable with Selenium, that is, you can freely mix calls to Helium to calls with Selenium. So in your case, you could add the Helium library to your project and when you extend or maintain it, at every step, choose whether you want to perform a particular step with Helium or Selenium.

oblio 13y ago

I hope you succeed with your project, but sorry, I feel that your pricing is batshit insane, pardon my French. $200 per year subscription for 1 machine for the basic license with support only for the installation, basically. And probably bugfixes, I'm guessing. If for whatever reason I'd like to create a 3-4-5 VM test farm I'd have to pay $600-$800-$1000 per year. And, again, subscription. If I don't pay after one year I cannot use this anymore. Combined with the closed source factor, I really don't like it, sorry.

mherrmann 13y ago
Thank you for the honest feedback and the good wishes. Here's why we think our subscription model makes sense: In our evaluation (heliumhq.com/AutomatingGmailWithHelium.pdf), developing a script with Helium took 75% less effort (man-days) and 66% less code than a script written in pure Selenium. The average developer salary in the US in 2010 was $90k a year(http://money.usnews.com/careers/best-jobs/software-developer/salary http://money.usnews.com/careers/best-jobs/software-developer...). Say this developer works 260 days a year, so makes roughly $350 a day. If it doesn't take him 75%, but only 25% less effort to write and maintain some web automation code, then each day of him working with Helium saves the company $87.5. This means that after about 11 working days, using Helium will have paid off, leaving potentially 249 more days in the year during which to reap Helium's benefits.
- hyp0 13y ago
  Most developers aren't scripting web interaction fulltime. This gives you a target: in which businesses are they doing lots of it? Have some copy on your website that speaks to the managers of those specific businesses - since they are the ones who decide and pay for it. The scenario plays out: developer is sick of testing, hears about Helium, tries it, it works great, he badgers his boss to buy it, boss looks at website, says this is fantastic, let's buy 100, he goes to the next tier of management for approval, and has all the answers for their concerns.
  - mherrmann 13y ago
    Very valid points. Especially the barrier that the developer is not the one who makes the purchase decision is one we have already encountered in a previous product.

adambenayoun 13y ago

@mherrmann - There are various ways you could monetize Helium and be open source - here are a few ideas. All of them assume that you will be open sourcing your code. The reason for open sourcing this would be to basically achieve wider adoption which will in turn allow you to monetize 5-10% of your audience (Enterprise customer for example). 1. Open Core Licensing - You could create a community edition and an enterprise edition. The community edition would be completely open source and available for free. While you work on the community edition you could identify the 5% of additional features that certain customers (Enterprise for example) would pay for. I think this is a pretty fair way to balance between giving away a free product and creating an enterprise/professional edition where you'd charge a license fee from customers who would have the ability to pay for it. One of the challenges with this model is to make sure you find the right balance between the community and enterprise edition since some people will be upset that certain feature aren't released in the community but make it into the enterprise edition. 2. SaaS - If you open source it and gain widespread adoption - at some point it might makes sense to create a service that allow users to run these tests on the cloud and create a complete suite of features around it. Many developers are happy to pay a service fee for using an hosted version of the open source software that allow them to not deal with hosting, patching and servicing that software. If you do that releasing it under the AGPL will give you a competitive advantage since if someone would like to create a hosted service and improve the open source software, they would have to release all changes to the community (or license a commercial version from you), however if you decide to add some secret sauce in the hosted solution, you ARE NOT required to release it to the community since you could license it under a commercial license to yourself. 3. Offer professional services, support and training - Once developers will start using this in their workflow and start being dependent on that software, they will want the peace of mind of paying for support (or the ability to contact you and ask questions). You could have various SLA of support. For examples: Community edition (FREE) would have access to community forum where users could help each other - at first you'd seed that forum with your own support to kickstart the community. Then you could offer several level of support, from email (9-5 or 24/7) to phone support to various customers. Additionally you could offer up to a certain amount of training or consulting to write custom tests for customers who will need your help integrating this into their workflow. Most often people will opt for paying for a basic license even if the software is free just so they have someone to nag and talk to if things go south. There are more ways that you could monetize open source - if you found this reply useful and would like to learn more - feel free to reach out to adam (at) binpress (dot) com - I am the co-founder at http://www.binpress.com http://www.binpress.com - the marketplace for commercial open source - we're on a mission to help developers monetize their open source projects.

Edmond 13y ago

I read through the comments and see you are catching a lot of flack for being closed source and daring to charge. My advice, do what you think makes sense for your company. You seem to have already done some cursory market research and I am guessing based on that you've decided on your current course of action...stick with it unless you have a good reason to change direction. Feedback is definitely important and useful but take it with a grain of salt. The HN crowd is a rather biased one and doesn't really reflect the broader dev world. Maybe try attending some dev meetups where you are likely to get a more diverse opinion. You've already quit your day job to do this, unless one of these folks is going to be paying your rent, you should absolutely focus on monetizing your product. In terms of the open vs closed source issue, I do agree that dev products should make their source code available, but that is only so it is easy to fix problems and address security concerns. You don't have to make it "open source", as in: allow people to freely alter and redistribute. I use this same approach with my company's product, which is also a dev tool (see my profile if you want to check it out).

mherrmann 13y ago
Thanks for the realistic and encouraging words. I was beginning to feel like a bad human being for charging for my work ;-) So you give the source code for your product to your customers, once they have bought it?
- Edmond 13y ago
  Yes most of the source code is included with the product. There is a small portion of it reserved for commercial entities, mainly the source code for our middleware, but even that will be included in the future.

duked 13y ago

Hi, I like the idea and I used watir [0] in the best to do a lot of automation but I fail to see what's different with Helium. Can you please tell me what are the differences besides python vs ruby ? [o]http://watir.com/ http://watir.com/

teh_klev 13y ago

First of all let me say that I have no problem with paying for software, even closed source or otherwise. I already pay a chunk of personal money for JetBrains tools and stuff from RedGate to let me get on and do my job more efficiently, and my company does the same. However your license condition: "If you want to run Helium on another machine then you must first remove it from the computer you were using it on previously." I work across a few different machines - work PC, other work PC and PC in lounge at home, VM's etc. This license condition just isn't practical or financially viable for solo developers or small dev shops who work like this. Do you actively check for multiple installs under the same license i.e. with a registration server? Altova XML Spy used to do this and it quickly got binned after the first year's license came up for renewal because they messed up the licensing records (PC crashed, couldn't de-register in-use licenses etc, hassle, hassle hassle) and we had developers working in VM's for a bunch of different projects all at once. Yes we could defeat the LAN sniffing it did to find out if two copies of the XML Spy were running with the same license, but it was too much effort and we resented having to do this - despite each dev being properly licensed. Vendors such as JetBrains and RedGate license the software to me/company for use by a single developer/user, I don't have restrictions such as "you must first remove it from the computer you were using it on previously". I/we are happy to buy licenses for each developer on our team "using" the software, but not for each and every VM or dev env a single developer is working in. As such I haven't bothered to let my colleagues know about this tool which sounds pretty cool, nor have I tried to download it (forcing me to part with contact details to try something really puts me off). I understand that you have to eat and pay the rent, but even for a company like ours, that has a fairly generous budget for development tools, this type of "per-installed machine" license is considered hostile for the type of tool being sold. I'm generally not a negative person when it comes to "Show HN" and I truly appreciate the efforts people put into their projects whether it be for a paid-for product or showing off some hacks or tricks, but your license....it frustrates me.

mherrmann 13y ago
I see. I'm very sorry to hear that you are so frustrated with the licensing scheme. We should also offer "floating" licenses which are not tied to a particular machine. Would that be OK for your needs?

mherrmann 13y ago

We have now added a Social License to our Purchase page (http://heliumhq.com/purchase http://heliumhq.com/purchase). It gives everyone who tweets about Helium a free license!

resu 13y ago
That's an excellent idea :)