Hi! I work on the documentation for Balanced. I'd love to hear your feedback. What do you not like? What would you like to see us improve? What do you like about Stripe's docs? I'm currently working on updated documentation and welcome any feedback you have. https://docs.balancedpayments.com/1.1/overview/
You're right. That tutorial could be made much more clear. In fact, this guide and others are being extensively rewritten. The example itself is specific to charging a Card. Therefore, the guide assumes you have an existing Customer since Customer creation is a separate topic. You are correct that the card_uri is an example of one that would be obtained from the previous example. Let me clear up how to charge a credit card.
A requirement of the current API is that a Card or BankAccount must first be associated to a Customer before it can be used. This is mainly due to the fact that v1.0 of the API is very Customer resource centric, something that's changing in the upcoming 1.1 release. A Customer resource will no longer be required to charge Cards.
If you have any other questions feel free to hop in #balanced on freenode IRC. We love questions!
Thank you for the update. I'm glad the project is still progressing. Also, thanks for mentioning Michal Papis. I know he's been working hard on binary builds of Ruby for both RVM and Tokaido.
Chrome has essentially 3 modes in which you can display pages. Windowed, Full Screen, and Presentation. If users use windowed, they have to manually size out the window to the screen bounds. Full screen mode obviously shows the page full screen. Presentation shows it full screen without the tab and address bars. Unfortunately, both the Full Screen and Presentation modes render other displays useless with the OS X fiber weave screen.
Chrome has to be relaunched from time-to-time for updates or system restarts. Users are left up to restoring "Recently Closed" tabs and windows or sizing out the window again. Sometimes users "close all windows", "minimize all" or hide the application without thinking about the one containing the "dashboard" view in the background. These inconveniences become distracting and require users to always be careful to remember that they have that one view they never want to dismiss.
Looking Glass was designed to avoid these issues. It doesn't render your other displays useless when presenting a web view full screen. It's meant to be a set-it-and-forget-it solution. Users can still do their normal work without fear of accidentally closing their "dashboard" view. A major concern of web-baseed kiosk application is that it's easy for people to navigate away from the page because the address bar is easily accessible. In Looking Glass there isn't an address bar immediately available for users to change the desired location. In the future, I imagine Looking Glass will also include a password lock feature so the start page URL cannot be changed by anyone who is not an administrator.
These are the main v1.0 differences between Looking Glass and Chrome's page presentation modes.
