Responsive Design with Amazon Checkout - e-commerce

A client is looking into using Amazon Checkout (http://www.amazonservices.com/content/amazon-checkout-payments.htm/ref=as_left_cba#!customer-experience) for the e-commerce portion of their site. They would also like to creative the site responsively. Since Amazon Checkout is not responsive, I presume this can not be done. Does anyone have any experience with this or have a bit more knowledge about the flexibility of Amazon Checkout making this possible?

IMO as web developers it is our job to do our very best to thoroughly research a requested API or service, and most times the API or service's competitors as well. As webworkers we can sometimes play a huge role in helping our clients to make the best choices for their technology service providers. This includes full disclosure when offering services that benefit the developer/firm, as well as plainly laying out the pros and cons in non-geek, plain English.
That being said, if your client just won't budge and is clinging to a non-responsive or stodgy, requirement-laden integration (read: non-responsive <iframe>) consider using design and user experience to draw a clear line between your pretty responsive site, and their ugly old code from 1998.
Consider using things like modals to differentiate the checkout experience, or simply use a target="_blank" to fire off a new tab or window, just make sure the user can easily find their way back to your site after the checkout is complete.
Another alternative might be to look into creating 1-click buttons if you are interested in having a modified shopping experience on a mobile-size screen.

Related

Advantages of Auth0

We have a web platform with 5 sites. Authentication is implemented with login/password only. My management told me that we need to add social login with Google and Facebook and for it I should look to Auth0 solution.
I checked it, it's look quite interesting but could somebody give me the real benefits of it's integration to our system what is quite difficult today? Price for 10 000 active users is 1440$ per month and I'm asking myself if it is really so difficult to implement social login?
In past, I created myself a simple prototype that logins with Google, it did not take a lot of time.
I suppose that everything is not so simple, so what am I missing and why do we have to buy this solution instead creating something simple ourselves?
I stumbled upon this question when I was researching about using Auth0.
I came to these conclusions, but your mileage may vary.
Here are some of the pros of using Auth0:
Almost any webapp you use is going to implement authentication. This is table stakes and there are lot of cookiecutter solutions for various frameworks, but can be hard to get it right and secured. One less thing to maintain and worry about when you are building your product. Their starter free plan is sufficient for most startups' needs.
Auth0 has got SDKs in various languages and a ton of documentation. Its easy to integrate it with your application.
It provides compliance with various standards(Ex: HIPAA), if that's a key requirement for your product.
Auth0 is not without its disadvantages. Remember that you are offloading your entire user data to a 3rd party app in exchange for flexibility. They do offer a way to migrate this data back to your app in case you need it, thus avoiding any vendor lockin.

Kimono Desktop Stopped Working?

Anyone having trouble building API's with the new Kimono Desktop app. When I click create API the browser just stays on create API screen loading but nothing happens.
I even tried building an API that is the same as one I built when Kimono was still in business and no luck.
My existing api's still run and pull data fine.
Working just fine here.
Just a shot in the blue...did you install the new extension specifically for the desktop app? The old one can't work anymore since Kimono disabled the online service.
You can't build new APIs I think - only existing ones. :( Said something like it was not the acquiring company's policy to provide this publiclu available service but since they did not know how many businesses depended on their APIs they decided to allow existing APis to run.
You can also use their software for replace the online API. But it's an abandonware.
It's working great but on some website I can create new API because of an error.
I just find a possible (free) product that can replace Kimono : Datascraping.co.
They will include an REST FULL API within few days / weeks, as they said here.
It's a good software, but comparing to Kimono Desktop it's a little much more complicated.
Kimono got bought out and it's not working anymore.
Import.io is good but it kinda expensive for me. I've tried the free trial before but see the price starts from $249, so... https://www.import.io/standard-plans/
I don't have any progamming skills so I know very little about some web scraping frameworks like Scrapy.
You may want to look at this new web scraping software called Octoparse.
In case you want to know, here is the link:http://www.octoparse.com/
It takes a little time to begin. But they have rich tutorials on the website. Plus it doesn't require programming skills.
They provide cloud-based scraping service and API access.
You can use it to create API but you have to pay for the service. Free version doesn't have the API and cloud service.
I've been using it for 2 month with the Standard plan $89, which a lot cheaper than import.io. So far so good.
Hope it would be helpful for you.

Strategy for modeling a multiple web app subscription system

I am working on a system using php/mysql where I am allowing users to subscribe monthly to various, small browser based web apps. Each app will have different subscription terms and plans. The apps are all currently built and they reside within the same framework.
I am in the modeling phase so I am looking to make this system as flexible as possible wheren the terms from one plan to the next will vary. Any thoughts on how to elegantly model this?
Rather than building this yourself you could look into using something like Zuora.com. Please note that I haven't used these guys or have any affiliation, I just remember reading something about services like this starting to emerge for web-app publishers needing a simple billing/metering solution.
Of course, you also need to consider which payment gateways you support, but I think that Zuora does that behind the scenes.

Creating a login section - Im new an need some serious direction please!

Alright. So I am new, I know my way around html pretty well, and have gotten by for a while now doing so. But today I am presented with a seemingly simple issue.
My client needs the ability for users to create their own LOGIN/PASSWORD, my client wants to be able to MANUALLY approve visitors. And he want to be able to track how many times they login.
The login section will just be about 4 pages of PDF file downloads.
I cant imagine this is the hardest thing in the world, I just have no clue where to even start. Perhaps there is a code already written, as things like this are done every day using forum technologies...
Please help!
It may also help to mention that I am using Dreamweaver cs4 on a MAC
I'd check out Ruby on Rails if I were you. It's pretty easy to get something quick up with it that you can have users create accounts with that send e-mails to the client with approve/reject options, and be able to track downloads and users via MySQL or other databases.
I've found Agile Development with Rails to be a great source of info on how to do stuff like this (they do an online bookstore as the book's example) and with a little modification I think it should work for what you say you want to do (and the book is pretty cheap as far as programming books go).
If you want just really basic static login features without lots of coding, you can start with Password protecting your pages with htaccess. You can password protect directories like this without any effort at all. This way, you can be sure that your login routine is secure.
Then, you can continue with advanced features like account administration and login statistics. These will require some programming skills.
Tracking count of user logins should be easy too. You can put simple PHP code to the source of protected pages that will save the info about login to the database. This will require you to study some basics of databases. You can use plaintext files which is not as clean but much easier and it will allow you to export info for your client more easily.
If you want to do it profesionally, you should invest in learning about web development or hire someone to do it for you. These tasks might not be trivial.
Have you worked with PHP, ASP.Net or some other web language yet? What you're trying to isn't too difficult in the grand scheme of things but it may be somewhat challenging if you haven't programmed before and/or haven't had any experience with web development.
(P.s. Alter your question as a response and comment on my answer when you're finished.)
As you are looking into Ruby on Rails, take a look at bort which is a RoR app skeletton with RESTful authentication included, it should help (Chris Bunch answered on the general RoR question).
There is also this bort fork. There is also Authlogic which may be easier to work with.
Have a look at the ASP.net Membership provider and also the login controls which provides the UI for the login as well as registration screens out of the box.
Here is a Multipart Series on ASP.NET's Membership, Roles, and Profile
If this is too complex than probably you can also design you application from scratch using ASP.net. If you don't know asp.net than the best place to start is www.asp.net it has several videos and tutorials which would help you get going soon.

How would you go about making an application that automatically retrieves your bank account balance twice a day?

I'm building a utility that will hopefully keep my wife in tune with how much money we have available.
I need a simple secure way of logging into my bank account and retrieving the balance.
Something like mechanize is the only method I can think of. I'm not even sure if that would work given the properly authenticated https that banks use.
Any ideas?
Write a perl script using LWP::UserAgent. It supports HTTPS connections. The only issue might be if the site requires javascript.
Web Client Programming with Perl has a few examples to get you started if you're not too familiar with perl.
If you really want to go there, get these extensions for Firefox: Live HTTP Headers, Firebug, FireCookie, and HttpFox. Also download cURL and a scripting language that can run cURL command-line tasks (or a scripting language like PHP or Perl that has access to cURL libraries directly).
I've started down this road for some idempotent GET tasks like getting PDFs of the S&P reports (of the stocks I track) from my online brokerage, and downloading the check images for my bank account. Both tasks are repetitive and slow ways of downloading data to my computer that the financial institutions don't provide any way of making it easier.
Here's why you shouldn't: (as a shortcut I'm going to call the archetypal large bank, brokerage, or other financial institution "BloatBank")
BloatBank is not likely to make public their API for accessing this kind of information. So it can change any time and all your hard work will be for naught. Whenever they change their mechanism, you'll have to adapt.
If BloatBank finds out you've been using automatic scripting to try to access your account information, they may ban you because you've violated their terms of service.
You might screw up, and the interaction between the hodgepodge of scripts on BloatBank's server, and your scripts that access your account, might cause a Bad Thing like closing your account. Testing this kind of script is tremendously difficult because you don't have any documentation about how their online service works, and you don't have a test account you can mess with.
(a variant of the above) You think you're safe because you're issuing GET requests. But BloatBank is just a crazy bank that doesn't know anything about REST, so there are some GET requests that can mess up your account.
If someone else does use your script to maliciously sniff your online password or mess with your account, any liability coverage from BloatBank may disappear because you've opened a security hole.
Why don't you teach your wife how to login to the bank herself? Or use Quicken (or Mint, etc) and teach her how to use the auto-download feature?
Have you checked out Watir? It is fantastic for automating web-browser actions. And since it's written in Ruby, you can take the results and store them in a DB (or email them to yourself) if needed.
If you are open to AIR, I'd say build an AIR app. I have worked with mechanize and I think it's cool. AIR gives you similar features with a richer GUI (see HTMLLoader and DOM manipulation of webpage).
If I were you, I'd simply pull the page and manipulate the DOM to suit my visual needs.
Please, if you find this easy to do for your bank please post your bank's name. If I have the same one I'll be closing my account.
More to your question. The process of loading a web page inside of your code rather than in a browser can be a black art, especially if their is any javascript involved. Your best bet would probably be embedding the IE Web Browser control in your app and then simulating key strokes and mouse clicks to arrive at your balance page. Then scrape the HTML for the balance.
I could try paying for Quicken and letting it do the balance downloading. Then I'd just need to find a way to get the number out of the software automatically.
This way I'm not violating any terms of service and I'm also reducing security risk since all "hacking" goes on locally.