Hacker News new | past | comments | ask | show | jobs | submit login

How much app traffic by data volume is video and audio?

There are some natural divisions I'd make generally to Web activity:

- Document-oriented content: mostly-static text and images. This is the domain of the web browser.

- Multimedia: audio and visual. Here I vastly prefer an application which can natively manage, organise, queue, and filter content. I do make heavy use of a podcasting app, and occasionally listen to Internet radio. I hear some people may use music or video streaming tools.

- Commerce. Shopping really should be divorced from the browser for far too many reasons.

- Applications. Truly interactive tools. Where the line between "Web" and "App" lies specifically I'm not entirely sure, but I can see much of what's presently provided through JS being made browser-native (wins for consistency and familiarity, probably a loss at feature development, though this may not be a bad thing), and classing "App" as "requires programming and persistent data store".

How well that holds up / sells I can't really say, though I've been advocating this for very nearly a decade:

https://old.reddit.com/r/dredmorbius/comments/256lxu/tabbed_...




>- Commerce. Shopping really should be divorced from the browser for far too many reasons.

What are those reasons? It seems to me that browsers are perfect for shopping as shopping is essentially browsing a product catalog. It's all basically document oriented content, static text and images, some short videos.

Sharing links is absolutely critical for shopping. Leaving product pages open for later is how many people research what they may want to buy. Product pages need to be indexed by search engines and be clickable by everyone, including on desktop.

All data lives on the server. There's little interactivity and no content creation. Offline use is rather pointless because the product database is on the server. There's no useful background activity. Notifications from shopping apps are mostly spam. Access to low level device functionality is neither necessary nor desirable.

There are far more shops than anyone wants apps. Desktop remains an important platform for shopping. So there needs to be a fully featured website anyway.

>- Applications

I think for applications it depends on where the data lives and whether desktop is an important platform. That's why essentially all business apps are web first unless their purpose is content creation and complex editing.

The real limitation of web apps is local data. There's no way for a web browser to reliably store data locally. Even though it sometimes looks as if you could use various forms of local data in a browser, on closer look it always turns out to be fragile, unreliable and only really useful as a cache.


Rationales:

1. Reading is not transactional or remunerative in most cases. There are exceptions (subscription-based content). Those might still be supported without going full-blown shopping, though in general I'd prefer alternate monetisation mechanisms.

2. Shopping involves payment methods and creates tremendous privacy concerns. Both of those are problematic in a generalised browser, to the extent that commerce sites are increasingly limiting which browsers they function with, which is to say, commerce is not a generalised Web capability. Payments functions could be removed from my generalised browser. The commerce-oriented app would have specific attention paid to security and privacy measures.

2a. My uparmoured Web browser using auto-deleting cookies, uMatrix, uBlock Origin, Ghostry, and other features to fight against surveillance and general Web annoyances plays poorly with most shopping sites as is. This means I've got to specifically remove armour to use such sites. This becomes more complicated when having to support others, at work or home, similarly.

2b. Information leakage between non-commercial browsing and commerce-based activity is a major concern and increasing threat. App-separation would provide a further firewall between the two.

3. A hypertext commerce platform could be URI based much as the present Web is. There are non-HTML URIs (ftp:// mail:// news:// doi:// ...). A "shop://" or "httpc://" transport (HTTP Commerce) would clearly distinguish shopping from other Web traffic and invoke the shopping application itself.

4. A possible risk would be that a large and well-resourced commerce provider might decide on delivering its own commerce app, or capture development of that app in much the same way as, hypothetically, a major Internet advertising entity might conceivably optimse a dominant Web browser as an advertising-delivery mechanism. These cases would have to be regulated by a conscientious, empowered, and principled competitions / anti-trust agency.

5. A standardised and capabilities-limited commerce application should reduce the use of dark patterns, or at least make them more difficult and apparent when employed.

Specification of a commerce-oriented application should reflect interests and concerns of vendors, shoppers, competition regulators, finance and payment processors, and advocates for groups of concern (the elderly, disabled, minorities, unbanked, etc.). The limited focus would make this far more tractable than for generalised Web browsers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: