I'm going to make some more changes today - I'll deploy it on stax tomorrow.
Add a few other problems - * Display of messages doesn't work in IE7 * Display of longer URLs on stream page is a problem. On Mon, Mar 8, 2010 at 10:21 PM, Anne Kathrine Petterøe <[email protected]> wrote: > Woohoooo Dick!! > Thanks a million zillion it looks awesome :D > > > On 8. mars 2010, at 13.27, Richard Hirsch wrote: > >> The new UI is on Stax (http://esmecloudserverapache.dickhirsch.staxapps.net/) >> >> Many probs - some big (OpenID doesn't work, public timeline doesn't >> work, resend, reply, conversation don't work) and small >> (layout-related ones, old static texts) still exist. But the basis is >> there in the branch >> >> D. >> >> On Mon, Mar 8, 2010 at 9:11 AM, Richard Hirsch <[email protected]> wrote: >>> On Mon, Mar 8, 2010 at 8:58 AM, Vassil Dichev <[email protected]> wrote: >>>>> The public timeline can be useful in the early days of a microblogging >>>>> service, as I have recently discovered with the introduction of SAPTalk >>>>> at SAP. While there are only a few users of a service and the social >>>>> graph is very sparse, the public timeline is the easiest way to find & >>>>> follow new people. >>>>> >>>>> Once the service is established, the public timeline is much less useful >>>>> - but it's still quite a good way for complete newbies to get a feel for >>>>> what's going on. Without the public timeline, new users have a chicken & >>>>> egg problem to deal with - they access the service, see very few (if >>>>> any) messages, and wonder what the big deal is with all this >>>>> microblogging nonsense and don't come back for 6 months. >>>> >>>> Very good point. To clarify, what I don't think is a good idea is to >>>> keep real-time updates for the public timeline. Neither Twitter nor >>>> identi.ca show messages in real-time, but a snapshot. This should be >>>> OK for us, too. >>>> >>>> To be sure, it would look cool to show the message flow in real-time, >>>> as long as they come in quantity below a certain threshold. It doesn't >>>> make sense to show messages that come faster than one can read them, >>>> though, and the load would bring the system to a crawl. >>>> >>>> So the idea was at least to show the public timeline in a view >>>> separate from the default message stream and think about potential >>>> performance improvements later, which would enable some impression of >>>> real-time flow. For instance, if the public timeline is updated in >>>> batches and cached, this should be fine. >>>> >>>> How does that sound? >>> >>> Good idea. I'd like to have a public timeline that is updated in >>> real-time but using an "older" functionality you can get older >>> messages from the public timeline. >>> >>> The question is whether we can use the existing streams functionality >>> for this. Ideally, you could click on a link entitled "public >>> timeline" on the main page and the streams page woould be shown with >>> the public timeline active. >>> >>>> >>> > >
