combine views for conversations and individual posts

[FND]

I can't think of a reason why we'd wanna keep them separate

[stilkov]

Have we really not discussed this before? Unsure.

I don't know how to handle updates to conversations. Should they appear at the top? Inline within the conversation? Both?

[aheusingfeld]

I don't know how to handle updates to conversations. Should they appear at the top? Inline within the conversation?

I assume we're talking about the conversation view and not about the timeline. Personally I don't like the conversation view which is displayed inside the timeline of Twitter's webUI. But what I do love is the way they highlight the selected tweet inside of a conversation view. Tweets created before this are shown above and tweets created later are shown below this tweet. Sort in ascending order by creation timestamp.

I'd hereby like to suggest to do the same for our statuses app. :)

[FND]

I'm not sure we're still talking about the original issue here, which was to combine the views (resources even) for /conversation/<id> and /updates/<id>.

I don't know how to handle updates to conversations.

The way it currently works seems fine, or am I missing anything?

[aheusingfeld]

the original issue here, which was to combine the views (resources even) for /conversation/ and /updates/.

I understood Stefan's question in a context of visualization. Thus my comment above was on how we could display updates to the conversation view. But as I resume and look at the list of issues, this is actually the topic of #9 and therefore should better be moved overthere. Agreed?

[aheusingfeld]

I'd like to come back to my suggestion above

Tweets created before this are shown above and tweets created later are shown below this tweet. Sort in ascending order by creation timestamp.

With this applied we only have the /updates/{id} (no /conversations/* anymore) and a specific update's view could look something like this

Changes:

• added a current css class to the current li.post
• added the following css - as a very rough sample:

    <style type="text/css">
    .post { font-size: 0.8em; margin-left: 1em;}
    .current { 
        background-color: #FFD; 
        font-size: 1.2em;
        margin-left: 0;
    }
    </style>

[stilkov]

I’m fine with this, please use a PR if you want to.

[aheusingfeld]

@stilkov @FND @mvitz I ran into a situation where I'd like to have your opinions:
Currently we retrieve the reply-form for a certain post by querying /statuses/update/123 via Javascript and parsing the returned HTML. I now changed the layout of /statuses/update/123 to contain the whole conversation. This implies that at the moment the whole conversation is also loaded just to retrieve the reply-form in the main timeline page which seems a bit too awkward to me.

I was thinking to move the reply-form to a separate resource e.g. /statuses/update/123/replyform. On the other hand one could argue that a form is not a resource by itself. How do you think about it?

[stilkov]

A form to reply seems like a perfectly fine resource to me.

[mvitz]

I'm not a web expert but to me returning a form as resource seems fine, too. Maybe we should name the resource just reply instead of replyform?!?

[aheusingfeld]

Maybe we should name the resource just reply instead of replyform?!?

Why? It's a form, it's not the reply.

[mvitz]

You're right. I shouldn't work while watching football ;-)