Will we come to a "pay-to-hide-url" SSL certificate ? Kind of ridiculous imo.
Burying the URL
321–330 of 376 posts
Re: Burying the URL
#322Earlier quoted context omitted.
For kicks, try replacing "software" with "automobiles" in your paragraph. The innards of a modern car are incomprehensible to all but "the few elite", and its interface goes a long way to hide all that complexity. I only have the vaguest idea how it works, and am perfectly happy to outsource its maintenance to professional mechanics, because all I care about is that it works . This should apply to computers. My famil…
>This should apply to computers. No, no, a thousand times no. What happened to cars - the replacement of mechanical, inspectable, (dare I say it) hackable components with electronic black boxes was not a good thing. You used to be able to fix and replace most things in an automobile engine with parts from the local auto shop and a shop manual. No longer. Now you have to spend hundreds or thousands to get the correct…
That's not a problem with abstraction, though, that's a problem with the manufacturers.
You can have complex, highly configurable software that's still locked down, and you can have simple, abstracted software that's open source. It's not a result of the simplification of UIs.
Re: Burying the URL
#323Earlier quoted context omitted.
> The new change would just make the whole thing a search field. This is incorrect. Entering a URL into the field produces the exact same behavior as it does with this option disabled. Typing a URL and pressing enter goes directly to that URL. Typing part of a URL that has been previously visited (like "face" => " http://www.facebook.com/" ) will default to visiting that URL.
I think we can probably agree that the text field on google.com is a search field. However, if I enter "face" into the text field on google.com, then facebook.com is the top result. If I enter a complete URL like " https://news.ycombinator.com/item?id=7677898" or even "news.ycombinator.com/item?id=7677898", it turns it into a link to that page. The only difference between the search field on google.com and the URL fi…
> In cases where the google search gives the wrong response, chrome gives the same wrong response, for example on intranet servers.
What? Intranet addresses work perfectly fine in the chrome url bar, unless it 1) has spaces (which aren't technically allowed in urls, and you can type %20 to avoid) or 2) is only letters (which you can avoid by just appending a slash or something).
Also, if the omnibox automatically redirected to sites instead, then yes it would pretty much be identical. But it doesn't and it's not.
Re: Burying the URL
#324Just further reinforces my opinion that Google Chrome is a Bad Browser™
Not "bad" in the sense of rendering or security holes (Read: IE6), but bad in that "experiments" can be "deployed" to users at any time, and a company with the aspergian-tendences of Google has control over that.
Re: Burying the URL
#325Earlier quoted context omitted.
A car has a simple goal: get you from one place to another. A computer does not. It's a general purpose tool that is near infinite in scope and possibility. The analogy is a complete failure.
A car has that simple goal of A/B movement....for you. Plenty of other people want to hack with their general purpose mobility machine infinite in scope and possibility .
I think the stakes are really higher with a computer than a car. We use computers to communicate and transact with others. It's a tool for us to learn and acquire skills, connect, trade in business etc. It has almost become an accessory for the human brain. So it's important that users remain in control of their devices, can learn how they work and not be dependent on a few chosen ones.
Re: Burying the URL
#326Earlier quoted context omitted.
I'm smelling a possible reboot of the browser paradigm. There are a few fundamental uses I see, and they're somewhat distinct: • Reading. For which stripping 99.99966% of Web formatting would be preferred. If I got content-heavy sites in a form similar to what Readability, Pocket, Instapaper, etc., delivers, I'd be much happier. Well, slightly less grumpy. I found it interesting that the Kobo tablet was, for a while,…
You seem to be asking for a generic "Tablet" interface, with multiple compartmentalized apps/processes for each of your use cases. Want to read? I either fire up the Adobe PDF reader and load something from my history or I open my email/dropbox/trello card and tap an attachment, which opens up the PDF reader. Almost all the interesting ideas in academia come in .pdf format, not .html. It just fits our use case better…
Mostly no.
Having file-format-specific reading utilities is stupid, awful, and is precisely the type of Windows-centric (and to a lesser extent Mac-centric) behavior I absolutely loath.
Applications centered around tasks however are a bit of a different story, and that's more of what I'm describing.
For reading, Adobe's an absolutely horrible example. Particularly on tablets. Don't make me remember the time I was buried to my waist in a colo cabinet trying to sort out load balancer issues while reading the 300+ page manual on my Android smartphone using the Adobe reader app ... which would reset to the front page each time it got kicked out ... which is precisely what was happening as a recruiter was calling me despite my repeatedly hanging up on her (and having net nil reception regardless). There are some modestly better PDF readers (say, evince), though must fail on the basis of not positioning the text optimally for reading.
Contrast with a stunning exception to the usual rule that online readers are crap: the Internet Archive's book reader. I discuss it briefly here: http://redd.it/1w0n83
The beauty of it? It autocrops the page to the visible content on it. Screenshot: http://i.imgur.com/Reg8KLB.png
You can further maximize the browser (F11) and remove the navigation elements so that _all_ you are seeing is the text you're reading. Page navigation is quick and intuitive. The entire thing is, incredibly, better than any desktop PDF viewer I've encountered.
What I'd really like is something somewhere between Calibre and Zotero: that will manage a selection of documents, organize and manage them, spawn viewers (preferably good and useful viewers -- Calibre on Linux fails massively in this regard). And, if I specify it, renders everything with minimal markup.
As for shopping: it's not that I'd fire up the Amazon app, I'd fire up the shopping app. You want a standard, uniformly designed client with solid security, not a mash of individually created apps, each with its own security flaws and excessive permissions.
Splitting shopping from web-browsing would also prevent surveilling users across the Internet from the shopping interface itself.
For specific application-based tools. Some sort of general app framework that could be fired up. The main distinction between it and the reader would be that a reader app would assume that it's valid at any time to dump state to disk and bail, whereas you could configure an app for how you wanted it to behave (I might want a monitor to be up 24/7/365, while a social networking app could shut down if I haven't interacted with it for 15 minutes).
Re: Burying the URL
#327Earlier quoted context omitted.
You seem to be asking for a generic "Tablet" interface, with multiple compartmentalized apps/processes for each of your use cases. Want to read? I either fire up the Adobe PDF reader and load something from my history or I open my email/dropbox/trello card and tap an attachment, which opens up the PDF reader. Almost all the interesting ideas in academia come in .pdf format, not .html. It just fits our use case better…
Academia is mostly standardized on arxiv - I can read papers from 12 different journals and they're all in the same format there. The rest of the web hasn't got there yet - if I want to read 12 different blog articles I have to navigate 12 different kinds of styled pages.
What's the arxiv format if I could ask?
Re: Burying the URL
#328Earlier quoted context omitted.
It might test well in metrics, but this is the kind of thing that points out why purely data based decision making can be dangerous. A-B testing assumes users will all behave the same in the future as in the past. But people's future behavior is dependent on their present behavior and experiences. With repeated exposure to URLs more people will learn how URLs work. Hiding URLs means that people will never be able to…
I already really dislike that win7 hides the filepath, and lies about it in many cases. It makes me click on the bar to actually see where I'm at in the filepath, please don't take that design mistake and apply it to the web.
I hope you've never used a mac in that case. Good luck finding a filepath with them. One of my biggest annoyances with mine right now.
Re: Burying the URL
#329Well, the location bar has always been one of Google's biggest competitors, which was pretty much won by Google after they integrated search. This is the next step...
Re: Burying the URL
#330As someone who hasn't used Chrome, I couldn't even make sense of this phrase: "Enable origin chip in Omnibox". WTF does that mean? No non-technical user is going understand that gibberish. I think it speaks volumes about Google's take on usability.