should work nicely. Add 'minimum-scale=1' to the meta tag's content to enable rasterization (better FPS when scrolling etc.)
You also have a bug in your markup which causes content to overflow outside of the viewport, resulting horizontal scrolling being possible at 1x scale when it shouldn't be.
This is because the #benefits row should be wrapped by a containing element with 15px left and right padding to balance out the Bootstrap row element's negative margins.
This issue is actually present on other pages as well. You'll want to add 15px left/right padding to the #support element, the #login element, and the .register element on their respective pages.
Typically, rows in Bootstrap are intended to be wrapped by a div with either the 'container' or 'container-fluid' class, which add the aforementioned padding.
The beauty of the Bootstrap grid is that the rows' negative margins allow grids to be nested without squashing columns with ever increasing gutters. This negative margin comes at a price: it adds to the containing element's width, meaning that padding must be added to eat this inflation.
Finally, the mixpanel link is clickable just beneath the clients image, when the button is actually at the bottom of the page. This is because the image is positioned relatively and offset by 250px, yet the containing anchor is not, and appears in its normal place.
I noticed that the Features page is a bit broken, probably not finished yet. The markup is a bit odd-looking to me. Not because Angular's involved, but because it looks like it tries to re-invent some wheels Bootstrap already has covered.
I'm not an Angular developer per se, as I've largely avoided frameworks by rolling my own over the years, but I did mock-up what might be a simple but effective way of structuring the page using Bootstrap's grid system.
The trick would be to use whatever the Angular equivalent of Bootstrap's jQuery-based tabs is.
I hope users who would like to see bulk messages on their phone chose to opt-in (manually, not auto-opt-in). Your terms of use do not demand this.
In the US: "FCC rules ban text messages sent to a mobile phone using an autodialer unless you previously gave consent to receive the message"
I would wonder deeply about opt-in rates as well. How are you keeping track of how much users enjoy receiving these messages? (Not just click rates because people might click something they hate to receive)
Also, confusingly, your terms of use state:
> You agree that You will not use the Service to send.. "promotional materials"...
But that's what's shown as an example on the front page?
Thanks for the feedback - SMS is a highly regulated industry and we follow all rules and regulations as specified by the TCPA and relevant case law. Our terms reflect these regulations. You should take a look at the full clause you identified "...That contains spam, non-permitted, unsolicited or unauthorized advertising, promotional materials, chain letters, pyramid schemes, gambling or any other form of solicitation". The key modifiers are 'non-permitted, unsolicited or unauthorized'. When a subscriber opts-in, they authorize the messages. We require explicit opt-ins for all subscribers in our service, regardless of whether they opted-in using another service.
Our business model is built around keeping subscribers opted in. When subscribers decide they no longer want to receive messages, we lose money. We track satisfaction by examining - among other variables - opt-out rates, click-through rates and response rates. The crux of our business is subscriber satisfaction and we take it very seriously.
Not related to the company and remembering off the top of my head, but I believe the rules state that two commands must be implemented by all SMS short code users: HELP and STOP. HELP returns information about the service whereas STOP must remove someone from the system instantly, after a final text (may be) sent.
I started to write something like this for my non-profit projects using Twilio, but it's crazy feeling to have to reinvent the wheel and do something so rudimentary. Will definitely try to use your service, Matt, but here are my suggestions:
- having a single opt-in code is not enough;
- it would be nice to offer lower prices for non-profits;
Thanks for the feedback and for creating an account! We do plan to release an API in the coming months. We'll also take into account your thoughts on opt-in codes and non-profit discounts, smart thinking.
This may have been mentioned somewhere but I don't see it on the pricing page: is there limit on how many campaigns or total messages I'm able to send in a month, or do I just pay per subscriber? For example, if I have 100 subscribers and run a single campaign at the end of every month, that's a lot less volume than having 100 subscribers and running a campaign every day. Are both options still costing me only $10?
Thanks for reviewing our product! We built Locent to help you reach customers more effectively using SMS (text messaging). Think of us as Mailchimp for SMS. We help you build a full text marketing program in minutes. All the ordinary email use cases apply with text messaging, we just have higher read rates and conversion rates particularly on smartphones. Really appreciate your feedback!
Slightly off topic, but I wish there were a mailgun for SMS service. 10,000 (or whatever number) free messages per month, a simple API, key, and secret, and boom. You're ready for sending out monitoring alerts for your side project that won't cost you anything until you're big enough to need to pay for it.
Thanks for checking us out! We do plan to expand user profile data to include further demographic information. Combined with forthcoming grouping functionality, you'll be able to target users for messaging based on a range of different variables as well as A/B test messaging across a subgroup.
Until the phone image loads (which took 6.1 seconds according to chrome timeline on fast internet), the page looks not so great: http://i.imgur.com/8aIDB4Y.png
Is this available for use in South Korea? We're an on demand cleaning service in Korea (http://getmiso.com) and use SMS for a lot of purposes but would love something like this.
Yes, you can use developer APIs like Twilio, Nexmo or Plivo to create your own SMS application. Carriers have different ways of identifying behavior they dislike in their network - if you're transparent about what you're doing, follow the rules, and get opt-ins from your subscribers you shouldn't have issues.
The specific limits vary based on a number of factors like volume per period, inbound/outbound ratio and so on, but carriers empowered the short code industry (5 or 6 digit phone numbers) to allow mass messaging to happen on terms they're comfortable with. When you create a short code, you specify what they should expect from you and if they approve you get to send 30+ messages per second.
That said, DIY gets complicated very quickly in this space (hence why we built Locent).
If you just want something for personal use, this is easy to setup with SNS on AWS. I've used it to send a text to myself when my favorite snowboarding resort has a favorable snow report.
On the surface we operate on different business models. CallLoop charges a flat rate per month with overages charged on a per message basis. That means they charge you a flat rate whether or not you succeed with your target subscribers.
We charge you per active subscriber per month, meaning that you only pay for people who have agreed to receive your messages. We have skin in the game to make sure you do well. If you don't, we don't get paid.
Firstly, since you're using a responsive front-end framework (Bootstrap), you should configure the viewport meta tag:
should work nicely. Add 'minimum-scale=1' to the meta tag's content to enable rasterization (better FPS when scrolling etc.)You also have a bug in your markup which causes content to overflow outside of the viewport, resulting horizontal scrolling being possible at 1x scale when it shouldn't be.
This is because the #benefits row should be wrapped by a containing element with 15px left and right padding to balance out the Bootstrap row element's negative margins.
This issue is actually present on other pages as well. You'll want to add 15px left/right padding to the #support element, the #login element, and the .register element on their respective pages.
Typically, rows in Bootstrap are intended to be wrapped by a div with either the 'container' or 'container-fluid' class, which add the aforementioned padding.
The beauty of the Bootstrap grid is that the rows' negative margins allow grids to be nested without squashing columns with ever increasing gutters. This negative margin comes at a price: it adds to the containing element's width, meaning that padding must be added to eat this inflation.
Finally, the mixpanel link is clickable just beneath the clients image, when the button is actually at the bottom of the page. This is because the image is positioned relatively and offset by 250px, yet the containing anchor is not, and appears in its normal place.
To fix this last issue, replace this:
and with this: