esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: New branch for UI
Date Mon, 08 Mar 2010 12:27:38 GMT
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 <hirsch.dick@gmail.com> wrote:
> On Mon, Mar 8, 2010 at 8:58 AM, Vassil Dichev <vdichev@apache.org> 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.
>
>>
>

Mime
View raw message