3 ms·
>This is the reality of knowledge work that none of these conceptualizations address: it’s hard (in very specific ways), some of it we don’t want to do, and the
by colllectorof 8y ago
>This is the reality of knowledge work that none of these conceptualizations address: it’s hard (in very specific ways), some of it we don’t want to do, and the work we don’t want to do piles up and becomes dominant simply because it remains undone.
Let me rephrase this for you. A lot of so-called "knowledge work" is just tedious, mind-numbing bullshit. Not only that, but you have to plow through it while fighting information overflow and your own overly complex tools, while acting completely alone. There are no librarians on the Internet.
No wonder everyone craves distractions.
>In the context of the browser, how do we contextualize pages and interactions inside some abstract task?
This train has sailed off its tracks long time ago.
Browsers aren't real tools. They are designed to make for smooth information consumption so that Google and co can harvest your money and attention as efficiently as possible.
I can list several hundred things a web browser should do if it aims at being "knowledge worker's tool". Let me just give some categories:
1. Features for pausing and restarting work in different mental contexts.
2. Local personalization. Shit like Timelines should be local and user-controller. "This is too complicated, so let's let Facebook/Twitter/Microsoft do it" is a lame excuse.
3. Did you notice that browsers still don't have any good authoring tools? Every websites reinvents their own WYSIWYG. "Developer tools" have everything for debugging, but almost nothing for creations of stuff.
4. User-driven integration between pages. (For example, something as simple as "when I open this page, go to that other page, find all the entries with word X and paste it here".)
Bah, that's enough. I can continue, but I think the point was made, unless the reader doesn't want to see it on purpose.
- steve1977 8y agoBrowsers aren't real tools. They are designed to make for smooth information consumption Well yeah. They're browsers, that's what they are. "To browse: an act of casual looking or reading."
- TheOtherHobbes 8y agoThey're not really browsers - they're web page viewers. The views are organised by the needs of the source technology - "pages" generated by a web server - not by the needs of the user. A lot of useful features - cross-referencing, comparisons, task-based content searches, dynamic content update notifications - are either impossible or poorly implemented on the server side. There's never been an active browser that tries to integrate information instead of being a dumb page viewer with tabs and some form filling options.
- TuringTest 8y agoTo be fair, every time someone tries to advance in the way of an integrated information tool, it gets a lot of backlash at tech sites from people saying that "a browser should be a browser and just show me the pages, nothing else". Not that everybody feels that way, but those people get vocal.
- chriswarbo 8y agoEarly on, the Web was imagined to have a plethora of "agents" (bots) which act on behalf of their users, extracting information from pages, following links, aggregating the relevant data, etc. This worked really well for search engines, but certain economic incentives crept in which pretty much killed off this idea. In particular: - Many sites gained revenue by advertising - Advertising only really works if a human is viewing it (it's possible to integrate advertising into the data, with product placement, "native advertising", etc. but that's more expensive than slapping some Javascript in some iframes) - Exposing data publically in easily parsed formats will mostly stop humans from viewing the page. Hence so much data is now in silos. - Exposing services, like search, to bots can get expensive. Hence the rise of API keys. There are other reasons too, like scraping being hard and fragile due to styling having too much influence over markup (CSS helped a little; a more radical attempt was sending raw XML and creating the page via XSLT). The rise of Javascript-only sites, and the difficulty of implementing all of the many JS APIs that a site might try to use, has also hindered alternative user agents. The end result is the Web being dominated by a handful of user agents: a few search crawlers and a few user-facing browsers :(
- TeMPOraL 8y ago> A lot of useful features - cross-referencing, comparisons, task-based content searches, dynamic content update notifications - are either impossible or poorly implemented on the server side. Dynamic content update notification is a solved problem - how many sites ask you daily to enable notifications? It's an issue of will, not way. As for others - those are really client-side concerns, they should be implemented in the user agent (i.e. browser). > There's never been an active browser that tries to integrate information instead of being a dumb page viewer with tabs and some form filling options. Agreed there never have been (to my knowledge) an active browser that's fully suitable for knowledge work. That said, the few features there were supporting, to paraphrase Pólya, the intelligent reader, have over time been diminished or removed from the browsers. For instance, both RSS feeds and user-styling used to be first-class features of browsers; both are now either invisible or gone.
- TuringTest 8y agoThen we need to create the category of builders as the base tool for web work, and relegate browsers to a secondary role.
- C1sc0cat 8y ago"Browsers aren't real tools." oh yes they are you probably haven't worked pre browser based systems. eg just before I switched to the web in 1995 I worked on an oracle forms system. To deploy a pilot system to 5 seats the Other developer and I went to Liverpool and spent 2 day setting up those 5 people - this required feeding 15 or 16 floppy disks in the right order to install the oracle forms product. As I said to my boss after the project was done imagine the savings if your rolling this out to 500 people and you could use the existing browser.
- TeMPOraL 8y agoThat has nothing to do with knowledge work; the core solution in your example isn't even the browser, or the WWW - it's the Internet in general, which allows a company to avoid the logistics of shipping software on an actual (air)ship. You could achieve the same with an FTP client. Using a browser as a runtime for your application has its own benefits and drawbacks, but that's another topic. GP's point is that browsers ain't real tools for working with knowledge. I wholeheartedly agree. Today's browsers are complicated application runtimes that allow vendors to serve content however they wish. Vendors of Internet services have their own goals, of which helping the user is one of the least important. That's why UX on the web is one of horrible inefficiency and near-zero interoperability. A proper tool for knowledge worker need to support end-user customization and end-user control over content as first-class concern.
- denniskane 8y agoThis and this, to the last two sentences. "Linux on the Web" (my baby) will be taking over in short order to rectify the situation (see my recent post history for more info). Been joyously hacking away on it almost nonstop since 2012. I've never felt a need or desire to work for anybody. That's all I do (when I'm not doing that thing I do when I'm out on the town).
- stevenwliao 8y agoWhat would (1) look like?