Improve format of overview data and embedded tweets

[stephengacheru]

[stephengacheru]

@brandonrosage This is one of the tasks that is needed for the pheme PL. @middle8media said it is a good idea to add this here as it might end up being used as part of core PL in the future. He also mentioned that there is a design process when trying to come up with something new. Your thoughts on this?

[rjmackay]

@stephengacheru I'm not clear what the change needed here is. Can you explain?

[stephengacheru]

@rjmackay Based on advice from @middle8media, I was seeking thoughts on the best way to present summarised data like the one above since we may face something similar on the platform one day.

[jshorland]

@brandonrosage any thoughts on this?

[brandonrosage]

I made a first, covert pass at addressing this in a purely CSS revision tucked into sprint-11. I improves the style of each field's label and the spacing around each field:

As we tackle "free-form surveys," we'll likely tweak this further to bring more emphasis to the field label. But today, we're only assuming the variety of custom field types we offer. And I think tis solution addresses them reasonably well.

As for embedded tweets, since they're not a typical form field type, I'm not certain how much time we should put into designing for them. I'd prefer embedded tweets literally be Twitter-defined embedded tweets. But if they must be data objects within Ushahidi, then we'll make sure we have a pattern for that content type.

[stephengacheru]

@brandonrosage I initially tried something close to that but had to change it for Pheme because it took up too much space and there was likely going to be lots of info being display. So I had to think of a way to present it without taking up too much space.

As for the tweets, that was my initial thoughts too but according to @tuxpiper the tweets were being pulled from a database so I made some minor tweaks to what we are already using for comments

Here is what I've initially come up with for Pheme. It needs further tweaking but I'm not sure if this would be useful for the Ushahidi platform.

[tuxpiper]

Just one note about tweets: rendering the tweets ourselves made sense for cases where we may need to enrich the information displayed . Also, Pheme should/would be eventually able to pull from social networks other than Twitter.

[brandonrosage]

Makes sense. Here's where I draw lines:

If we're trying to represent a "tweet," the absolute best way to honor that is to use Twitter's embedded tweet solution. That's a tweet; with all the dynamic data around it (e.g. replies, favorites, retweets).

If we're trying to import data from disparate communication channels, including Twitter, in the service of creating survey posts, then Ushahidi should provide a pattern for displaying that data.

Another way of putting it is, if a tweet is imported with the intent that it become the source material for a deployment's post, its content will be abstracted into the custom fields for the survey it's assigned to. It will no longer be a living tweet. It will be a tweet that got transformed into something else. In this case, we already have a solution: The content will have the same visual treatment as any other post.

But if a tweet is imported with the intent for it to be displayed as a tweet -- just in another context, like a deployment, rather than someone's Twitter timeline -- then we should use the universal convention for displaying a tweet and avoid rolling our own thing.

[tuxpiper]

I subscribe Brandon's views, the absolute best way to just represent a tweet is to use twitter's embedding facilities.

Beyond that scenario, I'm not sure what is the general right thing to do. Several considerations may come into play.

One such consideration that comes to mind is content licensing. I'm not sure if twitter content comes with a license that may still apply after taking such content and putting it in a different context such as a Ushahidi post.

[brandonrosage]

@jshorland In the interest of moving this issue down the line, I think there's two issues here:

1. Improve the presentation of each field in "Post detail" view.
2. Improve the presentation of tweets as children of a post (as opposed to tweets as the source material for a post).

Regarding No. 1, I think we've done that. In fact, it's implemented in the current sprint.

Regarding No. 2, I think we have a solution and an open question.

The solution is, if a tweet is being referenced/embedded within the content a post's field, it should be rendered using Twitter's convention for doing so. The only other known reference to a tweet in Ushahidi is a tweet as the original source of a post -- the Twitter data source importing a tweet and transforming it into a post. And we already have a solution for that, as well.

The open question is: Is there a third kind of reference to a tweet that we need to design for?

I'd argue that, for the overall product, we don't. Pheme essentially wrote custom code for a new custom field: Tweet(s). And we don't have any plans to implement such a custom field in the product.

Can we therefore mark this issue closed?

[Sunairaa]

Hey @Angamanga i am outreachy candidate , is this issue still available? can i work on it?

[Angamanga]

@Sunairaa Sorry its outdated (most issues in this repo are). Check here when you are ready with the issue you are currently working on: https://github.com/ushahidi/platform/issues?q=is%3Aopen+is%3Aissue+label%3A%22Community+Task%22