galaxy-hub
galaxy-hub copied to clipboard
EU features list
Here's where we can attempt to list all the individual features present on galaxyproject.eu which we may want to re-implement in the unified Hub.
Feature
It provides the middle pane for many Galaxy instances
Moved to #1380
Feature
Generate pages without the window dressing (NavBar)
There are many pages on the .eu site which are just content - no navbar or other chrome. It's necessary to, for instance, provide a middle pane for a Galaxy instance. They also seem to generate other content-only pages for inclusion in Galaxy instances: https://github.com/usegalaxy-eu/website/#duplication
- It looks like the *-galaxy.html layouts mainly differ in that they lack a navbar (
_includes/header.html
). - The
_posts_plain
and_events_plain
directories seem to be for this.- They're actually just links to
_posts
and_events
, so every post and event gets duplicated with a header-less version.
- They're actually just links to
- Most of these end up at urls determined by the
collections
key in_config.yml
.- e.g.
_events_plain
pages are at/event/:path/plain.html
(like /event/2016-04-04-conda/plain.html) - or
_posts_plain
at/posts/:year/:month/:day/:title/plain.html
(/posts/2021/11/25/ghelp-stats/plain.html)
- e.g.
Implementation
It's possible to use an alternate Layout instead of Default.vue.
The current Layout is actually just a global component which was imported in main.js
:
import DefaultLayout from "~/layouts/Default.vue";
export default function (Vue, { router, head, isClient }) {
// Set default layout as a global component
Vue.component("Layout", DefaultLayout);
Done
This was implemented in #1365 with the BareArticle
collection.
Feature
Automatically inferring date from filename
There are some files with no date in their metadata which still end up with a date presented on the page. For example: _posts/2021-02-14-smorgasbord-starts.md yields https://galaxyproject.eu/posts/2021/02/14/smorgasbord-starts/ I can only assume it's inferred from the filename?
Feature
❌ Tweet Wall
https://github.com/usegalaxy-eu/website/tree/master/tweet-wall
Usage
Copying the conclusion from Bjorn here:
its not needed for the migration
Feature
✔ Widgets
Looks like they provide their news and events feeds as independent pages so other sites can embed them with iframes. See their explanation. https://github.com/usegalaxy-eu/website/tree/master/widgets Result: https://galaxyproject.eu/widgets/news.html
Usage
Copying Bjorn's comments about the usage of these widgets:
Those are very high, we use them inside Galaxy webhooks. This means those are displayed when people submit Galaxy jobs.
Done
Implemented in #1491.
Feature
✔ RSS feed
The _config.yml
shows they have jekyll-feed, and indeed there's a /feed.xml live on the site.
Hopefully we can just use a Gridsome plugin like https://gridsome.org/plugins/gridsome-plugin-feed
One potential hitch is that if we want to give people a drop-in replacement for the .eu feed, we'd want to filter for only eu posts.
Usage
Copying the conclusion from Bjorn here:
Very important for a few users!
Done
Implemented in #1397.
Feature
Events ical format
The _events_ical
directory is there to render the list of events in .ics
format.
It's actually a link to _events
, meaning all events will be duplicated in ical format.
- The template is
_layouts/event-ical.ics
.
Still not sure what url this ends up at, though.
Feature
Automatically inferring date from filename
There are some files with no date in their metadata which still end up with a date presented on the page. For example: _posts/2021-02-14-smorgasbord-starts.md yields https://galaxyproject.eu/posts/2021/02/14/smorgasbord-starts/ I can only assume it's inferred from the filename?
Posts are usually retrieving the data from the filename. Events on the other side do take the dates from metadata. However, both take the date from the filename to hide posts and events which filename is in the future. This enables us to create events and posts that are only published automatically in the future. But Nick this does not need to stay like that. If you think the data should be metadata also for posts, we can do that, We can script that, change all our markdown when we migrate. It would just be good if we can preserve the links, or redirect them. A few posts are hightly read.
Feature
Tweet Wall?
https://github.com/usegalaxy-eu/website/tree/master/tweet-wall
This we used during GCC and displayed that on a big screen. I think its a cool feature, but lets move this to a separate issue, its not needed for the migration.
Feature
Widgets?
https://github.com/usegalaxy-eu/website/tree/master/widgets https://github.com/usegalaxy-eu/website/blob/master/widgets/index.md
Those widgets we use Galaxy webhooks. So if you submit a Galaxy tool, you will see once in a while the latest events/news... Just a different, more compact view of events/news.
Feature
jekyll-feed plugin
The
_config.yml
shows they have jekyll-feed, and indeed there's a /feed.xml live on the site.
Very important for a few users!
Feature
Events ical format
The
_events_ical
directory is there to render the list of events in.ics
format. It's actually a link to_events
, meaning all events will be duplicated in ical format.* The template is `_layouts/event-ical.ics`.
Still not sure what url this ends up at, though.
webcal://galaxyproject.eu/event/2021-12-23-GalaxyWS_SFB/event.ics.html
You see that on each event on the top:
Thanks for working on this! There are several sites, like AU, BE, Africa that are using this website, so all time you spent here will enable the others sites to migrate as well. Its worth it I think! Thanks!
Feature
tools.yml
Looks like a database mapping tool names/ids to toolshed locations. Seems to only be used to generate urls to tools in index-*.md middle panes (see index-rna.md)
* .md page uses an `include` like `{% include tool.html id="CoFold" %}` * Then `_includes/tool.html` queries the tools.yml database with `{%- for tool in site.data.tools -%}` * Then it generates a link to the tool with a template like `https://usegalaxy.eu/root?tool_id={{ tool[1] }}`
Strangely, there's a /tools page, but that's hardcoded in HTML in
tools.md
, and doesn't seem to be generated bytools.yml
. Perhaps because it's grouped into categories, which don't exist intools.yml
.
Upps, missed that one.
The tools.yml is just a convenience mapping of keys to proper tool-urls. This can be used for example on subdomains to link conveniently tools, e.g. in those markdown tables, without copying the URL every time AND more important, dependent on the subdomain the link is https://singlecell.usegalaxy.eu/root?tool_id={{ tool[1] }}
or https://rna.usegalaxy.eu/root?tool_id={{ tool[1] }}
This page https://galaxyproject.eu/tools is completely different and it is autogenerated every week, it's a plain HTML. See here: https://github.com/usegalaxy-eu/website/blob/master/.github/workflows/update-tools.yml You can simply take this GitHub action over and run this for all Galaxy instances.
Feature
Expanded Font Awesome icon set
We seem to not have as much Font Awesome support as .eu. Some icons work out of the box (fa-laptop
, fa-list-ul
), but others show up as an unrecognized unicode character (fa-slideshare
) and still others don't show up at all (fa-video-camera
).
You can see examples at /events/2021-10-sars-cov-2-training/
.
Feature
Display supporters
in footer
Moved to #1612
Feature
Structured article metadata
As described in #1315, certain metadata fields in .eu posts contain structured data instead of plain strings. We need to parse them and display them properly:
organiser
These are often dicts which contain keys like name
and email
.
location
These are often dicts which contain keys like city
, country
, and geo
(which itself contains a dict of GPS coordinates).
It looks like annotate_locations.py actually uses that data to search OpenStreetMap and fill in the geo
key for any posts that lack it. One caution about porting that to a Data Store API plugin: it looks like there's a built-in rate limit of one query per second, so it could take too long to do for every post.
Feature
Automatic article teases
.eu seems to automatically generate tease
s for their posts from the first bit of the content. There's an automatic function to do that in Gridsome.
When implementing it, though, it'd be good to somehow avoid displaying auto-generated teases in the article header, like we currently do for our manual teases. Because then it looks repetitive and weird.
Feature
Automatic article teases
.eu seems to automatically generate
tease
s for their posts from the first bit of the content. There's an automatic function to do that in Gridsome.When implementing it, though, it'd be good to somehow avoid displaying auto-generated teases in the article header, like we currently do for our manual teases. Because then it looks repetitive and weird.
It's debatable if this feature is good or bad. I could argument in both sides I guess. If you think we should drop it we need to bite the bullet and add tease to our articles.
It's debatable if this feature is good or bad. I could argument in both sides I guess. If you think we should drop it we need to bite the bullet and add tease to our articles.
From my side, I'd certainly prefer manual teases. But it's just a little extra work to auto-generate them.
Feature
Hiding footer
See _events/2020-10-22-RNA-Seq-Iran2020.md
:
# special hiding of footer since we want to do it manually.
hidefooter: true
39 events contain this key.
Usage
How many of these features are actually used or relied on?
Here I'm collecting specifics on what data would help deciding whether each feature warrants actually implementing.
Note: It looks like the ending .html
can be omitted from any of these urls, so remember that when checking the traffic stats. Also, you can omit the index.html
off any url that ends in it.
Widgets
What are the traffic stats for: https://galaxyproject.eu/widgets/news.html https://galaxyproject.eu/widgets/events.html
Events ical format
What are the traffic stats for: https://galaxyproject.eu/events//event.ics.html https://galaxyproject.eu/event//event.ics.html
Pages without window dressing
What are the traffic stats for: https://usegalaxy-eu.github.io/galaxy/news.html https://usegalaxy-eu.github.io/galaxy/events.html https://galaxyproject.eu/events//plain.html https://galaxyproject.eu/event//plain.html https://galaxyproject.eu/posts///*/plain.html
What are the traffic stats for: https://galaxyproject.eu/widgets/news.html https://galaxyproject.eu/widgets/events.html
Those are very high, we use them inside Galaxy webhooks. This means those are displayed when people submit Galaxy jobs.
What are the traffic stats for: https://galaxyproject.eu/events//event.ics.html https://galaxyproject.eu/event//event.ics.html
No idea, not sure if we know. Is this hard to generate? We should actually create a public GCalender out of that, or add this automatically to an existing one.
What are the traffic stats for: https://galaxyproject.eu/events//event.ics.html https://galaxyproject.eu/event//event.ics.html
No idea, not sure if we know. Is this hard to generate? We should actually create a public GCalender out of that, or add this automatically to an existing one.
@dannon is this what you worked on? I think that the only missing part was to add them to the existing GalaxyEvents
calendar
No idea, not sure if we know. Is this hard to generate? We should actually create a public GCalender out of that, or add this automatically to an existing one.
Yeah, so Dannon was working on an ics feed which would contain all events. It's a little different, but maybe that's close enough to say it supplants the individual event ics files?
Those are very high, we use them inside Galaxy webhooks. This means those are displayed when people submit Galaxy jobs.
@bgruening Very good to know. Are you sure these are the exact urls that are used, though? I just tried it myself (on usegalaxy.eu) and it showed https://usegalaxy-eu.github.io/galaxy/news.html, not https://galaxyproject.eu/widgets/news.html
Feature
Inter-post links
Each news (but not event) post has links to the previous and next posts so users can navigate between them without going back to the list of all events.
Yep, the .ics feed is live at https://galaxyproject.org/events/calendar.ics and will include any 'event' type content item; I think what @beatrizserrano is mentioning was piping all of those events into the existing GalaxyEvents
public google calendar. That turned out to be nontrivial and potentially messy (like for changes to events) to keep in sync. Still looking for better ways to solve that one.
Re: the "add to calendar" feature, it looks like we can also give an "add to Google Calendar" button without any ics file. Instead all we need is to compose a link to a particular Google Calendar url.
For example: http://www.google.com/calendar/event?action=TEMPLATE&details=We+will+have+a+presentation+on+Galaxy+on+AnVIL+by+Mike+Schatz&text=Galaxy+Community+Call%3A+Galaxy+on+AnVIL&dates=20220526T150000Z%2F20220526T160000Z
This breaks down to http://www.google.com/calendar/event
with these query parameters:
parameter | value |
---|---|
action | TEMPLATE |
details | We+will+have+a+presentation+on+Galaxy+on+AnVIL+by+Mike+Schatz |
text | Galaxy+Community+Call:+Galaxy+on+AnVIL |
dates | 20220526T150000Z/20220526T160000Z |
Bea gave some traffic data that shed some light on some of the questions above:
Widgets
What are the traffic stats for: https://galaxyproject.eu/widgets/news.html https://galaxyproject.eu/widgets/events.html
/widgets/news.html is the 8th most visited page in the last month. I didn't see events.html in the top 45, though.
Pages without window dressing
What are the traffic stats for: https://usegalaxy-eu.github.io/galaxy/news.html https://usegalaxy-eu.github.io/galaxy/events.html
/galaxy/events.html and /galaxy/news.html are the 2nd and 3rd most visited pages, far above the versions with navbars.
Here are all the versions of the events and news pages in the top 45 most visited pages:
rank | page |
---|---|
2 | /galaxy/events.html |
3 | /galaxy/news.html |
8 | /widgets/news.html |
27 | /news |
39 | /news.html |
41 | /events |
Feature
Filtering posts by tag
It looks like you can filter posts by tag with query parameters like so: https://galaxyproject.eu/news?tag=UseCase
Feature
The doi
metadata field
It looks like when a post includes a doi
field, they generate a link to the article next to the tags in the header. See: https://galaxyproject.eu/posts/2022/05/27/paper-tnbc/