Show your support for community science. Donate to Public Lab »


Question:Need your feedback on Tag pages

tommystyles asked on October 20, 2017 00:32
170 | 2 answers | shortlink


Hello Public Lab community! I'm Tommy, and I'm working on a pro bono project through Autodesk to help out with improving the user experience on the publiclab.org website. You will start to see some questions popping up here from my teammates and myself to get feedback from you, the people who use the site, on what works and what doesn't, or what can be improved. Thanks in advance for taking a minute to weigh in, and helping us improve the site for everyone!

We are focusing our current efforts on Tags pages. Here is an example.

A few questions to get things started:

  1. Do you visit Tag pages often? Do you find them useful?
  2. How do you find and navigate to a Tag page?
  3. What differentiates a Tag page from a Wiki page in your mind? Do you find both useful? (example of a wiki page here)
  4. What is the most useful info or feature you get from a Tag page?
  5. What (if anything) do you dislike about Tag pages? What info there is not useful?

That's good for now. This is just the first volley, more questions to come.

We appreciate any time you can spare to drop us some quick answers here and help us make the site an even better resource for making a difference in your world.

Cheers,

-Tommy



website design tags ux ui usability

question:ui



4 Comments

cfastie 3 months ago

Hi Tommy,

I just learned last month that when you search for a tag that has been used at publiclab.org you can get two different results. If the tag you search for (or the tag you click on) is associated with a wiki page, the search results page you get will have a nice header with the main image and first paragraph of that wiki page. Below that will be the search results which will have any research notes with that tag (I don’t know whether wikis with that tag are included in the search results). If there is no wiki page associated with your tag, you will get just the search results. It is not clear to me how a wiki page gets associated with a tag, because more than one wiki page can have the same tag, and sometimes the title of an associated wiki page is different from the tag (e.g., tag = balloon-mapping, wiki = Balloon & Kite Mapping), and sometimes a power tag (e.g., activities:balloon-mapping) seems to be sufficient to associate the tag with the wiki.

I assume when you refer to tag pages you are referring to search results which have the nice header from an associated wiki page. If that is so, my thoughts about tag pages are 1) that they are new and maybe not many publiclab users have noticed them, 2) that they are very good-looking and helpful, and 3) they are somewhat mysterious. Most tags don’t lead you to tag pages, and it’s not always clear why.

I would like to know how to deal with the one tag many wikis issue. What happens when two wikis have the same tag? I would also like to know how to deal with the many tags one wiki issue. If you search for the tag balloon, you don’t get the tag page for balloon-mapping. If you search for the tag skypod, you don’t get the tag page for skypod-gps-logger. Is there a way to redirect searches for the tag skypod to the tag page for skypod-gps-logger?

Thanks for your efforts. Tag pages seem to be a rather obscure topic to start with. Is there a reason that other user experience issues aren’t being addressed instead?

Chris

cfastie 3 months ago

Another thing that makes tag pages sort of mysterious is that you can get to one by searching for "https://publiclab.org/tag/balloon-mapping", but if you enter "balloon-mapping" in the publiclab search box (https://publiclab.org/search/balloon-mapping) you don't get a tag page, and the search results you get are rather unhelpful. Apparently search does not include tags. There are two things about the user experience at publiclab that seem strange, and one of them is that search doesn't seem to work like I expect it to.

liz 2 months ago

Only two things seem strange @cfastie ? ;) -- then perhaps we're doing better than expected! :D

gretchengehrke 2 months ago

@cfastie, I have those same questions too re: many tags, one wiki; one tag, many wikis. I'm hoping we can start creating primary wikis that are topic landing pages, which then could link to other wikis about similar topics or subtopics. That might start to solve the "many wikis, one tag" question with regards to how a wiki is selected to be the lead wiki for a "tag page."

Log in to comment

2 Answers

Via @liz note here:

Let's go back to basics on this issue :)

What is the goal of visualizing tags?

For me, visualizing tags is a way to visually depict associated tags, e.g. tags that appear together on the same content. For great example, see the color-coded clusters in @skilfullycurled 's visualization above. Clustering tags are important because they visually connect the website's presentation of community activity closer to what the Public Lab community culturally refers to as "research areas", or perhaps "topics" --> this is my actual goal with this entire issue.

Here's some background information: on our tags page (https://publiclab.org/tags) we write "We use tags to group research by topic" and encourage people to browse tags (currently only sorted by recent activity). This is an important way that we name, link to, and/or promote people to find and engage with topics. The Dashboard itself emphasizes recent activity. The Dashboard now features a "recently used tags" bar -- which is an important but partial step to the goal of seeing "research areas" or "topics".

To move forward, I am not interested in navigating by a graphic tag visualization (so 2007!), however, the clusters of activity provide an important additional way of connecting/navigating to topics. To achieve the goal, by which i mean the ability for the tags page to show which are the most interconnected tags, to communicate the breadth of connected topics in a research area, to navigate/connect to a research area, and to subscribe appropriately we do not necessarily need color-coded swooping arrows. Let's think about how to achieve these goals.

We might also consider mirroring publiclab.org/tags at publiclab.org/topics to make the language more accessible.


warren 2 months ago

I left a long response to this with a possible initial solution:

Cool, thanks Liz!

To try for one stab at a narrower feature towards this goal, what if tag pages (floating new name: topic pages...!?!) had a list of "Related topics", something like:

Related topics: water runoff wetlands turbidity

Where "related" means that (acknowledging that there are different ways to measure this, and that we want some "computationally efficient" way) these are the tags which most commonly appear on pages that already have the primary tag. So for the topic onions, we tally every page tagged with onions and take the top, say, five most commonly occurring tags

Small follow-up if the above sounds good -- would it be all right to do this solely for the most recent 20-30 pages? Even if this is just a starting point, that would make this easier to implement without worrying about it causing overall website slowness. There could be more complex ways around this, but this is the easiest way to get started.

https://github.com/publiclab/plots2/issues/1502#issuecomment-344799631

liz 2 months ago

quick question -- are "primary tags" the most interconnected tags, or would there be a manual step of choosing them?

Glad to see there is a way to get started on this. While I appreciate the computational need for "recent," it is also true that i find it nervewracking to meet my responsibility to helping people find the topics they are interested in when everything is calculated by recently modified. After we get this first step done, i might have a suggestion that we lean on prior work done by @bsugar that shows these clusters, and potentially also include some that are not recently modified.

gretchengehrke 2 months ago

I think we should distinguish between tags and topics. I think, while we still don't use the word "topic" widely on the site, we have the opportunity to be very selective and concrete with what is deemed a "topic." This might save a headache later.

For tag groupings, I agree with Liz that it would be really great to have a way to group and view that is not related to chronology. I'd love to see primary landing pages that are always at the top, and those can have links to wikis and research notes etc. Perhaps a landing page could have a section on common tags associated with this topic, etc.

liz 2 months ago

Hi @gretchen , do you have any more comments specifically on the interrelatedness of tags? That's what we are discussing here, rather than the adjacent navigation question of "primary landing pages always at the top." Here in this thread, we are working on developing how to -- for the first time -- show clusters of interrelated tags on Public Lab. I would love to hear any thoughts you have on clustering.

warren 2 months ago

Hi, @liz and @gretchen - unfortunately, there is a direct link between site slowness and capacity costs and database queries such as required by a non-chronological tag lookup. I spent some time after talking with @liz thinking about creative ways around this, but unfortunately this is one of the main reasons @bsugar runs these types of analysis offline, and that we don't crank through this level of calculations as part of the site's functioning. Sadly, even if a calculation took, say, 10 seconds, that would bring the whole site to it's knees. And since there are no limits to the # of tags per page, it's likely that some pages would take 10x or 100x that amount of time, halting other activity on the site while that runs. (if you google "optimize database slowness", you'll get about a million articles telling you NOT to run queries of this kind)

Not to be apocalyptic! I just want to be clear that I'm not just saying it'd be hard, but that the scope of this is far greater than calculating the most recent values, which is something we can move on immediately.

Barring a database specialist, and a relatively major infrastructure project, this may be a hard limit. I'd be happy to try to plan what initial steps could be on this, but my guess was that you'd be interested in moving forward on this faster than that.

Sorry to drone on, I just wanted to explain why I'm trying so hard to think around this problem! I fully understand why this function is important, I just don't know how possible it is to implement, so I'm offering what we definitely can do.

warren 2 months ago

Ah, and to your question, by "primary tag" I just meant the tag for the tag page you're looking at, so for /tag/onions, just onions. If we implemented this, the system would run automatically on all tag pages.

bsugar 2 months ago

Hey everyone! For what it's worth I was heavily inspired by this project Tag Overflow, the code for which is here and from an initial version, here.

My version didn't require any ongoing database queries because I just exported the tags table to csv and ran it from there. The visualization only uses the top 256 tags (I think). I'm not sure if you can have other processes concurrently running (as in workers?) but you could export that single table on a weekly basis and then run a program to calculate the rest. I understand that even a single process can block the rest of the website but were it possible to run a separate process concurrently, it's not a very computationally intensive at all to create the tag co-occurrence graph and export it to a form (json, graphml) for visualization.

Log in to comment

Also, this issue which will help us count all contributors on a topic will help generate a broader picture of topic-specific community:

https://github.com/publiclab/plots2/issues/1774

Thanks to Liz for pushing this along!


bsugar 2 months ago

For an interesting spin on this (all be it force directed) go to Tag Overflow and click on one of the tag nodes. : )

liz 10 days ago

it would be great if we saw pictures of contributors on the tag pages

Log in to comment

Sign up or Login to post an answer to this question.