Don't use the Web, don't build a "platform", build a peer to peer system, support threading, use local storage of both postings and read status information, use a native interface for fast and efficient navigation.
Or in other words: Re-invent NNTP.
Yes, NNTP has its problems, too, and could possibly use some additional features, but it's silly when you look at how easily you could/can follow huge discussions using slrn, and how badly current online discussion technology stacks up against that. It's all shinier now, but the usability is absolute crap for the most part.
I guess I should spell this out explicitly: Don't integrate data model and UI. That's the most silly thing about the web nowadays: Every instance of the same kind of content comes with a different UI, but without an API, even though it is all computer-readable data in principle. That is completely braindead, as far as the possibilities of information technology go. Wherever there is a discussion offered, I should be able to add it to the discussion software of my choice, so that (a) I have all the discussions in one place and with a consistent UI, which then can reasonably be powerful, as it's reasonable to, say, learn key bindings, for your one discussion client, as opposed to learning keybindings for every web forum out there, and (b) if you don't like the UI I am using, you can use a different UI that you like, and still participate in the same discussion. And in any case, native software is just so much more responsive than any of this web stuff.
It may be that we mean slightly different things here. I am not talking so much about the software architecture, but about the fact that the API between "front-end" and "back-end" should be the public interface. That does require a certain software architecture, though, of course ...
Every time I see attempts to use Twitter et al. as a "platform", I end up thinking how much better something NNTP-like would fill the role, if only it still had significant penetration.
Comments
Don't use the Web, don't build a "platform", build a peer to peer system, support threading, use local storage of both postings and read status information, use a native interface for fast and efficient navigation.
Or in other words: Re-invent NNTP.
Yes, NNTP has its problems, too, and could possibly use some additional features, but it's silly when you look at how easily you could/can follow huge discussions using slrn, and how badly current online discussion technology stacks up against that. It's all shinier now, but the usability is absolute crap for the most part.
I guess I should spell this out explicitly: Don't integrate data model and UI. That's the most silly thing about the web nowadays: Every instance of the same kind of content comes with a different UI, but without an API, even though it is all computer-readable data in principle. That is completely braindead, as far as the possibilities of information technology go. Wherever there is a discussion offered, I should be able to add it to the discussion software of my choice, so that (a) I have all the discussions in one place and with a consistent UI, which then can reasonably be powerful, as it's reasonable to, say, learn key bindings, for your one discussion client, as opposed to learning keybindings for every web forum out there, and (b) if you don't like the UI I am using, you can use a different UI that you like, and still participate in the same discussion. And in any case, native software is just so much more responsive than any of this web stuff.
I have the exact same views.
In one of the discussion on building the structure, I was amazed to find that people do not think in terms of API.
As for me, I have always thought of having 3 different layers/servers independent of each other. Front-end, Back-end and Database
It may be that we mean slightly different things here. I am not talking so much about the software architecture, but about the fact that the API between "front-end" and "back-end" should be the public interface. That does require a certain software architecture, though, of course ...
Just build your private API as a public API. That's what we've been doing and so far its turning out great
Yes ... But if the software arch does not decouple the front-end and back-end, then there are essentially no APIs.
An API approach is the best approach. Later it can always be opened to public.
This.
Every time I see attempts to use Twitter et al. as a "platform", I end up thinking how much better something NNTP-like would fill the role, if only it still had significant penetration.
NNTP had an adoption problem. Nobody built a mobile app for it :). Maybe someone can :D But twitter's more than just news.
I am not a big fan of peer to peer system, but will give it a look.