h a l f b a k e r yOutside the bag the box came in.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
In modern days, websites adopted the practise of turning their non-logged-in service page into a fancy landing page that introduces the service. However, this makes the service look lawful for non-registered users.
So... define new standard of not mixing landing pages with service, e.g., do landing
pages on specific directory, like /landing/, and let the users choose, when they want to see their advertising stuff. Instead, show the actual UI of the service immediately, without registration.
[link]
|
| |
//However, this makes the service look lawful for non-
registered users.// |
|
| |
I'm not sure what the problem with this is. The company
(presumably) has an introductory landing page because it
brings in customers. |
|
| |
If what you mean is that it is _awful_ for _registered_
users, then wouldn't it be easier to standardise on the
opposite - i.e. to have a specific subdirectory for the
service? |
|
| |
Visitors would go to "example.com" and see a description
of their fine service, while users would go to, say,
"example.com/ui/" which would, assuming that they're
logged in, immediately provide the logged-in interface. |
|
| |
This has the advantage for the business that they can still
show off their service to potential customers on the root
page. Advertising links wouldn't have to be changed.
If the user was not logged in, just a simple login screen
could be shown. (I don't think there's much gain to
showing active UI to guests, and it can have a whole
bunch of down-sides, like needing to transfer data into an
account when the user logs in, or create a new user while
holding state.) |
|
| |
This inverts the use case from someone adding stuff to a
url to be shown bumph to adding stuff to a url to avoid
being shown bumph - which I think is much more likely to
be adopted by the customer in practice. |
|
| |
I rarely buy from companies that don't offer a "guest
checkout". The requirement to register at all turns me off.
If, then, the purchase form only uses the information from
the registration form or there's so much as an email
verification I look for my merchandise elsewhere. |
|
| |
A company does NOT have the right to ask intrusive
questions of me as a cost of doing business. |
|
| |
//I rarely buy from companies that don't offer a "guest
checkout". The requirement to register at all turns me
off.// |
|
| |
Me too[1], but as I understand it the point of this idea is
somewhat different. Hopefully Mindey will return and
clarify, but here is what I understand of it: |
|
| |
Even in the absence of any registration requirement at
all, root pages can be an introduction or guide to the
service, rather than the service itself.
While this is useful to new users, it is sub-optimal for
experienced users. Particularly if it's a particularly heavy
page on a slow connection or computer.
The proposal is to have a standard modifier (i.e. a
subdirectory) which goes straight to the service. ~
Oh, wait - the idea as stated was the other way round
[2]. But anyway, I think it makes more sense this way,
because then it's a proposed (and useful) standard
instead. |
|
| |
[1] Well, I don't mind registering too much if I can see
how it helps, or I'm expecting to be a regular customer.
What I _really_ hate is having to ask for a quote rather
than seeing a pricelist, or even example prices for a
complex service. |
|
| |
[2] Which is maybe advocacy - but I don't think it
warrants an mfd for it. |
|
| |