# Question: Need your feedback on Tag pages

tommystyles asked on October 20, 2017 00:32
303 | 3 answers | #15072

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

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

Is this a question? Click here to post it to the Questions page.

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.

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.

Is this a question? Click here to post it to the Questions page.

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

Is this a question? Click here to post it to the Questions page.

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.

Is this a question? Click here to post it to the Questions page.

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.

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.

Is this a question? Click here to post it to the Questions page.

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.

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.

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.

Is this a question? Click here to post it to the Questions page.

Oops, sorry @skilfullycurled I hadn't remembered your last comment on this thread and replied to an inquiry from another contributor looking to implement some pieces of the tag visualization issue: https://github.com/publiclab/plots2/issues/1502#issuecomment-360310483

1. only running on the top 256 tags
2. caching weekly

I also responded over there, but I think that with all the work on the API, code cleanup and outreach, we could do a daily or weekly cached version of such a query, and be OK with 10-15 seconds total compute time per week. The rest would be run locally in the browser.

But a key is -- what are the steps to get from a list such as I cited in this comment: https://github.com/publiclab/plots2/issues/1502#issuecomment-360311857 -- like:

["whitebalance", [12476, 13575]], ["wi", [12143, 13067]], ["wi-fi", [11123]], ["width-of-dvd-grating", [12838, 12875, 12895, 12899, 12902, 12926, 12990, 12991, 12995, 12999, 13006, 13014, 13019, 13037, 13046, 13057, 13062, 13069, 13077, 13088, 13089, 13094, 13103, 13117, 13125, 13131, 13133, 13136, 13152, 13154, 13157, 13159, 13169, 13178, 13181, 13183, 13188, 13226, 13248, 13283, 13302, 13305, 13308, 13315, 13316, 13340, 13349, 13355, 13366, 13401, 13402, 13409, 13414, 13423, 13429, 13432, 13434, 13437, 13439, 13440, 13443]], ["wiki", [9048, 10956]], ["wiki-gardening", [10956]], ["wild", [11707, 11711]], ["wildfires", [14803]],


to a visualization like yours, and is this enough information to get there? Thanks!

Is this a question? Click here to post it to the Questions page.

To be fair, I think that as the site grows, this query will become more and more taxing on the database, and we may need to rethink this in the future. But at present I think we can do an initial implementation of this API call to produce the unique page IDs, grouped by the tags they use, as above.

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!

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

Is this a question? Click here to post it to the Questions page.

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

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

Is this a question? Click here to post it to the Questions page.

@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."

Hi Everyone,

Here is a preliminary review of the site and also some questions to better understand who the people in the community. https://docs.google.com/document/d/1796lMEwSjUawamKIYebbsSikFBBboVK5lZ6jZFKJLXI/edit?usp=sharing

It would be great to hear your thoughts and opinions!

Is this a question? Click here to post it to the Questions page.

thank you so much for this @julvie , i've started reading your great write-up and am excited to be in touch on this

Thank you again so much @julvie, i added so many comments i hope it's not too much! Would you be interested in coming to a 3pm meeting next Tuesday January 30th and hosting a discussion on this with us?

Is this a question? Click here to post it to the Questions page.

Hi Liz, it's certainly great to have a discussion going. An in-person discussion would be even better but I am based in Singapore. :( I hope you get a lot of insights that could help improve the experience on the site!

I mean, stranger things have happened....:) Thanks so much @julvie!