Well except the software is not as good as my iPad for even that.
I would have imagined a great native app to shop on amazon, but it does not exist, so I have to go to the web browser. And while the web browser on an ipad is an enjoyable experience, it's not on a Fire. It's slower, the soft keyboard is less convenient, the experience less snappy and the screen smaller.
The gold box is not well integrated.
The e-mails I receive from Amazon on my ipad/computer are useful, but not integrated. This should have been built as the mother of CRM devices.
The other complaints from users are valid:
a) No privacy, so anyone can see what movies I watched on the main page (so you prefer not bringing it to work) b) The cover flip UI is unusable if you have a lot of books. The iPad is more conveninient. Good luck being able to select book number 43 - and selecting the right one is hard. Usually the page flips and it open the next one instead. c) I inverted my fire because I don't find the location of the on/off button convenient, but the login screen does not make use of the orientation, so need to log in upside down.
The hardware is lacking a video out for movies (cant't cost that much) There is no external SD slot to expand internal storage So the device can't be use to view PDF's which I do a lot on my iPad.
So yes, very much v1.0 in both hardware and software. I was hoping it would be more convenient - for example to read in the subway - than my ipad but it's not.
Hope Amazon takes feedback and improve their feedback. Will be interesting how long they support the device.
I've build similar systems in the past. It's not a simple problem. In addition to a very robust and well thought network architecture and a very robust encryption architecture for the Credit Cards as mentionned in the previous posts you have to deal with:
Credit Card reconciliation - when you bill on a monthly basis, a lot of cards expire, are cancelled, this needs to be detected, the user informed the next time he tries to use the service, etc... There needs to be good adminstrative/financial metrics to track these.
You need very good operational interfaces and a strong underlying architecture so that people get billed when they should, and not when they should not. It's easy in cruise mode, but harder to keep track as financial processors or external connectivity is down, or after an upgrade, or system crash or other usual operational down-time.
Things get also quite complicated quickly if you offer multiple subscription services (monthly, yearly, first month free, etc...)
This stuff is hard to get 100% right (and it needs to be 100% right). I agree with the other post that recommend either a provider that already does that, or buying software that already does this.
This is a very common fallacy but one that is
easy to fix with good results. The most
effective way to 'test' a gui is not to test it
directly but to abstract out in an interface
what the elements of the GUI does. These
can be regression tested using the usual
techniques.
Doing it this way improves you code because it
also requires that your GUI code does no
application processing - Just human interaction
stuff. This often has huge payoffs later when
someone ask you to add a scripting language
to your system.
Actual final testing of the user interface can
be done manually and with GUI testing tools, but
the bugs rarely are endemically there (UI code
tends to be not so complexe and debugged
quickly). The majority of the problems tend
to be in the application and the state changes
forced upon it.
Doing this often causes to greatly improve your
internal architecture, worry about flow of
control within the app, in a context where it
can be more easily tested.
Slashdot Mirror
Yes, save the classic version. The beta has nothing going for it.
Well except the software is not as good as my iPad for even that.
I would have imagined a great native app to shop on amazon, but it does not exist, so
I have to go to the web browser.
And while the web browser on an ipad is an enjoyable experience, it's not on a Fire.
It's slower, the soft keyboard is less convenient, the experience less snappy and the screen smaller.
The gold box is not well integrated.
The e-mails I receive from Amazon on my ipad/computer are useful, but not integrated. This should
have been built as the mother of CRM devices.
The other complaints from users are valid:
a) No privacy, so anyone can see what movies I watched on the main page (so you prefer not bringing it to work)
b) The cover flip UI is unusable if you have a lot of books. The iPad is more conveninient. Good luck being able to select
book number 43 - and selecting the right one is hard. Usually the page flips and it open the next one instead.
c) I inverted my fire because I don't find the location of the on/off button convenient, but the login screen does
not make use of the orientation, so need to log in upside down.
The hardware is lacking a video out for movies (cant't cost that much)
There is no external SD slot to expand internal storage
So the device can't be use to view PDF's which I do a lot on my iPad.
So yes, very much v1.0 in both hardware and software. I was hoping it would be more convenient - for example
to read in the subway - than my ipad but it's not.
Hope Amazon takes feedback and improve their feedback. Will be interesting how long they support the device.
I've build similar systems in the past. It's not a simple problem. In addition to a very robust and well thought network architecture and a very robust encryption architecture for the Credit Cards as mentionned in the previous posts you have to deal with:
Credit Card reconciliation - when you bill on a monthly basis, a lot of cards expire, are cancelled, this needs to be detected, the user informed the next time he tries to use the service, etc... There needs to be good adminstrative/financial metrics to track these.
You need very good operational interfaces and a strong underlying architecture so that people get billed when they should, and not when they should not. It's easy in cruise mode, but harder to keep track as financial processors or external connectivity is down, or after an upgrade, or system crash or other usual operational down-time.
Things get also quite complicated quickly if you offer multiple subscription services (monthly, yearly, first month free, etc...)
This stuff is hard to get 100% right (and it needs to be 100% right). I agree with the other post that recommend either a provider that already does that, or buying software that already does this.
This is a very common fallacy but one that is easy to fix with good results. The most effective way to 'test' a gui is not to test it directly but to abstract out in an interface what the elements of the GUI does. These can be regression tested using the usual techniques. Doing it this way improves you code because it also requires that your GUI code does no application processing - Just human interaction stuff. This often has huge payoffs later when someone ask you to add a scripting language to your system. Actual final testing of the user interface can be done manually and with GUI testing tools, but the bugs rarely are endemically there (UI code tends to be not so complexe and debugged quickly). The majority of the problems tend to be in the application and the state changes forced upon it. Doing this often causes to greatly improve your internal architecture, worry about flow of control within the app, in a context where it can be more easily tested.