Re: [dev] Suckless e-comerce script proposal
On Thu, Sep 22, 2016 at 09:28:56AM -0400, Bobby Powers wrote:
> Hi Joseph,
>
> Joseph Graham wrote:
> > The principal is: most of the website is static. Static index pages. Static
> > item description pages. The item description pages link to a CGI script* with
> > an ID for the product in a query string. So for example
> > /cgi-bin/order?item=burgundy_shoes_23
>
> First, it sucks to expose the fact that you are using a "common
> gateway interface" script to the user - Use a URL scheme like
> "/checkout?item=dope_shoes" or something.
>
Hiding the internals of the system just for the sake of hiding them sounds like
Microsoft's philosophy.
>
> So what happens when you are out of stock on something? Do you
> re-generate the static pages? Or do you throw an error when the user
> tries to checkout? In the first case - you are re-generating (or
> re-caching) HTML in response to a user request, in the second, it is a
> sucky experience.
Just throws an error.
>
> > Becuase payment is by bank transfer user's data does not contain any financial
> > information, just address, name and email etc. However for privacy perhaps
> > user's data can be encrypted with asymmetric encryption before writing to disk?
>
> Bank transfer? How is depending on the user to visit another website
> (which certainly uses JavaScript and all the things you are trying to
> avoid) decreasing the overall suck your users are experiencing?
>
Well, they can just phone up.
> > -One CGI script, everything else static.
>
> Hopefully you are generating/compiling this static content from
> something, and not hand coding HTML on a ton of different pages.
>
Yep, hand coding.
> > -Can only buy one item at a time, no shopping basket. For shopping basket we
> > would need cookies.
>
> Buy one thing at a time, and re-enter my info a bunch of times in a row? Suck.
>
Well it depends what type of shop it is... if it's a computer shop it doesn't
matter since people don't normally order 2 computers at once.
> > -Payment by bank transfer.
>
> Ever wonder why existing web sites don't do this? Because it wire
> transfers are terrible. Either you force users to use a bank website
> (Cookies + JavaScript, so you have just lost your moral high ground),
> or you force them to drive to a bank, or call up a bank. Such suck.
>
The thing with card payments is that you give your card details to dosens of
different shopping websites, creating a large "attack surface" for those details to be
stolen. With bank transfer there's only 1 point of failure instead of dosens.
>
> If you are just thinking of suck as internal implementation
> complexity, you have the wrong mindset. You should be making APIs and
> user experiences that don't suck, even if that means you have some
> amount of (hidden to the user) internal implementation complexity. I
> don't care that YOUR life sucks less, I want you to help me make my
> life suck less.
>
> Besides, if you expect users to fill out an identical form for each
> item they want, and initiate a wire transfer on their own, you are
> going to go out of business.
>
> yours,
> Bobby
>
Thanks for feedback I appreciate it.
-Joseph
Received on Thu Sep 22 2016 - 21:51:29 CEST
This archive was generated by hypermail 2.3.0
: Thu Sep 22 2016 - 22:00:21 CEST