esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Kathrine Petter√łe <yoji...@gmail.com>
Subject Re: New branch for UI
Date Mon, 08 Mar 2010 21:21:08 GMT
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 <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