 Alright, we might get started as people start to struggle in. So I'm Andrew, I'm going to chair this session, and you might be wondering why is the emoji guy chairing this session? Let's just say we all say things we regret at the conference dinner, okay? But we're not going to regret, is this next few talks, and the first one is Mark who's going to be talking about the human-centered design journey. Thank you. Hi, before we start, I would like to begin by acknowledging the traditional owners of the land on which we meet today. I would also like to pay my respect to elders past and present. My name is Mark, I'm the UX designer at the Australian Biocommons. The Australian Biocommons is a digital infrastructure capability that supports Australian life science research communities. I'm a designer with no biology background. I specialise in user experience, user research, UI design, and generally for functional applications. I have built and scale and launch a variety of complex applications and systems for both public and the private sectors that are used by a variety of wide range of end users. So I've been a designer since the Dow up internet era, a long time ago, up until very recently I worked in design-led environments. Being design-led also means user-centered. Because we focus on the experience of the users and that shines through the strategy, planning, and daily activities. So Galaxy Australia, the growth has been steadily year in, year out across all measure of activity. Underpinning this growth has been constant feature improvement to the service, almost exclusively driven by decision made by the Galaxy Australia team that based on informed intuitions and learned knowledge. So despite developing features and solution based on learned knowledge is not always a bad thing. It is, it was getting harder for us to prioritise new features and improvement because there were no framework for measuring user satisfaction and service improvement based on user experience. Our knowledge of our users was also limited to two types. So like we will always say new users and power user, whether term we use, often when we talk about our end users. And we also had no comprehensive understanding in how Galaxy Australia fits within researchers research data life cycle. So our previous practice was we engage, our user engagement data. We do do some user testing, user research, but it was not shareable, not reusable and all accessible simply because it was, it wasn't set up probably there were no proper framework for that. And also we were building solution for a single user type because it was difficult to give consideration to various user skills, level needs and requirements. The features and solution we built were based on engaging with community leaders, subject matter specialist and learned knowledge. So the consequence of that was we often need to rely on user guides and training to help the end user to find what they need on the page and how to complete tasks with step-by-step instructions. So in order to provide better user experience and be more intuitive, Galaxy Australia is taking the human-centered design approach. So what is human-centered design? So human-centered design is an approach to problem-solving that put the people we design for at the heart of the process. So how do we do that? So it is very important for us to have a deep understanding of our user before we know how we have helped them and how we may do better to help them. So these are some of the user research method we use to help us better define and understand them. So we use user journey map and we use user experience surveys and then we create user persona. So what is a user persona? Usually it has a name, occupation, information, demographic, personal story, pen points and challenges. So basically we want to create a reliable and realistic representation of our key audience segment for reference. So here is an example of our user journey map. So as you can see on the left, we conducted one-on-one interview session, can be face-to-face or remote, with a wide range of people, including bioinformaticians, life science researchers, PhD students and e-research analysts from various institutions and domains. So based on, we're using the Alexa lecture research data lifecycle blueprint and we asked them to walk us through each of each stage, things like what tasks they need to get done. For example, on the planning stage, they might want to understand the research question, they might need to do some paperwork or they might need to do some sort of preparation. So they describe walk us through and also their touch point. For example, you know, how do they communicate with people, do they use Zoom, do they email that sort of thing. And the data report cell tree, report cell tree and also contacts, who do they need to talk to. They will walk us through. And then the challenges and pain points while they're doing that. So do they feel that a particular thing is quite annoying? And when they do mention what sort of pain point they have, then we will ask them, so when you're facing that challenges, what is the work around? So that will help us to understand how do they currently solve their own problem. And then we want them to also tell us how do they feel, you know, when if they're facing something great or if they're doing something that's quite annoying. So we want them to tell us it is frustrating, stressful or they're very happy with it or neutral. And then we also will want to know is there any opportunities from that particular stage doing all this stuff and also is there room to improve. So through their end to end user journey, we can clearly see when, where they need help and what problem they have, why and what are the future opportunities for us to consider, including quick wins. So most importantly, Galaxy Australia appears in more in more than one stage within the data lifecycle for some of the users, which actually will help us to explore the user requirements and to identify new use cases. So I think initially my own assumption was we Galaxy will be appearing on the analysis column, but it appeared to be sometimes appear in planning, sometimes appear in collecting and often come out in analyzing. So it's really good to know and really good to see. So here is an example of a user survey report. So we invited assisting user to do the survey to build user profile, particularly their role, research, domain, skill sets, level of experience, the screen gone black, skill set level experience within their expertise and their interaction with Galaxy Australia and their preferred platforms and services. So from that, here is a couple of personas, sorry, this is the user research example because screen went black. So this is the example of personas. So here we build the persona with the user journey map quantitative data combined with our user survey quantitative information, qualitative and quantitative information to construct this persona, help us to understand our user and enable us to make reasonable assumptions about their behavior, motivation and needs when building a solution for them. Along the way, we have received a lot of good feedback along this journey, but our focus is to identify and understand their problems. So just to highlight a few, our study showed that both our new and non-regular end user find Galaxy Australia overwhelming in that it is not intuitive and overloaded with options. It is not a system they think they can use without going through certain level of training and support. So for one, it is not obvious to them that they need an account to kickstart the process. Despite needing to know which tools and workflow to do their analysis, there is no clear UI indicating the order between data, workflow and tool or the steps. So as for the regular user, quite a big, a large number of people said the unhelpful error messages were timely for them to figure out exactly what the error is and what can they do to rectify it. So that is really popping out quite often. So these gaps enable us to adopt the human-centered design approach to solve real user problems and to improve their user experience. So we know all that, so what's next? So we would need to adopt agile framework to generate a backlog of user stories with a demonstrated UI design and acceptance criteria and engage with designer to ensure the design requirements is communicated clearly and we must practice shoulder tap with designer before deployment as a QC measure. So basically, get the designer, have a look at what you have developed to make sure that they're happy with it and pass on. Because the designer, design based on the research evidence, so it's important to align with that. We need to build a design pattern system and create or create a design style guide. So what is a design system, which is basically a complete set of standards intended to manage reusable components such as error message and so on, so the tone, the where, the pattern, how it shows is consistent. A design style guide is a document that contains design guidelines of each repeatedly used design elements like icons, button, heading, and point size. So these will give us the ability to quickly replicate UI components and prevent the bed of any functionality or appearance that could lead to unintended inconsistency. And we also need to have customisation capabilities and user experience awareness. In that, often, we have to develop a workaround solution due to very limited ability to make UI improvement. We also need to reduce what we want to reduce global Galaxy communication barriers despite of time zone. We want to be one of the Galaxy main UX contributor and have a framework to share and to feed our UX findings with the wider Galaxy UX community. Last but not the least, we will also conduct an accessibility evaluation to identify areas for improvement and to create a platform that understand and enable people of all backgrounds and ability. Last, I'd like to thank my team. Thank you for having me. Thank you, Mark. We don't have time for questions, unfortunately. We need to squeeze an extra break in this morning, so thank you very much. Please speak to Mark afterwards if you've got any questions. Thank you very much. Next up, we have Laila. Yeah, hello. My name is Laila. I'm from the Freiburg team. Today, I'd like to talk about UX and accessibility. This talk will be a bit of a mix. It's partially aimed at developers, but also I want to show a few of the things we implemented for end users. This is also aimed at basically everyone, how improving accessibility is like a team effort and what we can all do to improve this. We've heard these terms thrown around a lot in the past few days, UX and accessibility. I think it wasn't always clear like what is UX, what is accessibility. So I've written up definitions. I think that having a good UX user experience means that your interface is like as easy and straightforward to use by as many people as possible. And accessibility, also sometimes called A111, but please don't pronounce it like that. On the other hand, we have good accessibility means making your interfaces as easy and straightforward to use by as many people as possible. So you may be wondering why are these definitions the same? And that's because I like to treat these two topics as the same. I really think that good accessibility and good UX, they very much feed into each other and they're topics that cannot be separated. So here we have a few examples of what I think makes a good accessibility and a good UX. At the end of the day, it's for everyone. If you hear like accessibility, it is UX and everyone benefits from accessibility. So my first one is a bit for developers and I think that as web developers we have it kind of easy to implement good accessibility actually because the web browser gives us a ton of tools to improve this. And one of these tools which is very underused is semantic HTML. Semantic HTML is a standard for making the tags not just divs and spans how you used to, but giving them meaning. And there's a bunch of benefits to using semantic HTML. It makes it more approachable to screen readers and different types of interfaces to interpret these user interfaces in many different ways. So it's not just people that use the like standard go to way of using a user interface with the browser and the mouse can integrate it, but machines can read it to then again make it as easy to use by other people. And one of these examples which we also cleaned up a bit in Galaxy is headings. And that's the thing I see a lot used wrongly. So the headings come in different types. Next to a heading tag you always see like these small numbers next to it. And people tend to think they like control the size of heading. Like H1 is a big heading and H2 is a smaller heading. But this is actually not true. This is the heading level. And they do not indicate size, but they build up a tree structure for the browser to understand your document. Here I have an example of the structure. This can also be very important to help users of screen readers navigate your site. And this is a simple change for smaller site. It can be quite an ordeal for larger ones. And we tried to do this in Galaxy, so go through and fix up all the heading levels. But this is of course an ongoing effort because it's a thing that is very hard to lint in an app with like dynamic content as Galaxy as. Yeah, and one thing you can do to alleviate this is to detach the size from the level. So provide a utility class for your developers. They can resize your headings without having to change the level. Yeah, and I'd also like to mention the heading group which can be used to group in subheadings if you want to attach extra information to the headings. Yeah, and another thing we integrated in Galaxy is improved keyboard navigation. And one thing you can do to improve your keyboard navigation is when you use new, when you have new components is just like try to navigating them with your keyboard. This is our history item. And this is the new tagging component we have. And previously all these X's you see here, they were all like keyboard navigation targets. So if you had a lot of, a lot of tags, you had to like click 11 or 12 times just to get to your next item. So what we did instead is offer like an alternative way for keyboard users to remove their tags instead of having to click through all of these X's. Just enter the tag again and the actual completion will show it like you want to remove this and you hit enter and the tag is gone. So now the history item is a lot quicker to navigate and the tags are also a lot quicker to remove purely by keyboard navigation. And another example of this is in the history itself. It can be quite hard to select the right item because of all of these buttons in the history. They were also used to be like targets which were selected with the keyboard navigation. But now just the history items are selected. And once it's expanded, then you can navigate into the item. So this requires a lot less inputs from users with keyboards so that the history can navigate it, be navigated a lot more quickly. Yeah, next I'd like to talk about color and contrast. That contrast is mostly determined by perceived lightness. It's also a few different factors. And for this, people like to use HSL because it says like use saturation lightness, but I want to clear up the misconception that the L in HSL does not model perceived lightness. It models like a computer lightness, but that is not the same. I've got this example graph here. And as you can see, there is like white text on color. And at a few parts it gets very hard to read. That is because the varying in hue also changes lightness. This is a black and white picture of the HSL color spectrum. And as you can see, the perceived lightness varies wildly. And this can be bad for users because if you use HSL to like choose colors, you can accidentally land on very light colors and make your text very hard to read. This is also an issue we had a bit with the tags. There's a black and white view of the tags we had. They are generated. So they can be easier to distinguish from one another. And as you can see, some of these tags blend into the background perfectly. There's no way to see them at all. So we switch to an alternative color space called HSL UV, which does model the perceived lightness. And as you can see, the black and white levels, like the contrast, is a lot more visible. That is because it allows us like way finer control about the contrast. And what we also did is we added a partial outline, so it can be even more distinctive from the background. So try HSL UV. It's a fantastic tool. And also if you're not a developer, it can also be a fantastic tool because it has this really nice color picker. So if you're choosing colors for a presentation or for a slide or anything, I can really recommend this. It's all in a saturation and a lightness, and it gives you this whole range of colors, which all have the exact same contrast level. And I also like to talk a bit about the accessibility tools built in browsers. It can offer you like a really quick peek on your site, like how does this look to colorblind users? Can I navigate the site? And it also has a few other like high level checks, like is this accessible via keyboard, and has some a few issues which it can automatically highlight. Yeah, and last I'd like to talk about accessible fonts. So not all fonts are easy to read. Sometimes you have fonts where the letters like are very hard to differentiate from another. And it's very hard to tell letters from numbers, like a good example is the big O and the zero. They can be very hard to tell apart with some fonts. This is an example from the Atkinson Hyperlegible font, where you can see the one, the big I, the small I, and the L, they're all very good to tell apart even when blurred. And this is not the case for most fonts, not even for default fonts for systems. They tend to be really bad with this. Yeah, so here are some fonts which I think are some great candidates to use. It's first Atkinson Hyperlegible, which is what we also switched to for Galaxy. It is super reasonable and it is free to use. So there's little reason not to use it. I also wanted to show a few more cents, which is also quite accessible. I don't think it's as easy to read as Atkinson Hyperlegible, but it has the advantage of offering like a ton of variants. So if you need to display code, if you need to display like math symbols, or if you have like tons of languages you need to support, this is a very good choice. Lexand font by Google, it was designed for screen readers. The nice thing about this is you can variably alter the fonts width, and it will always adapt. And finally, we have the German DIN 1451, very good name, rolls off the tongue. This was developed by Germany to use on traffic signs. So it's like intended to be read very quickly in a moving vehicle, which makes it excellent to read. However, there aren't that good implementations. There is an open source implementation, but it has a very limited character set. But if you're on Windows, you can use Bandschrift, which is an excellent implementation, but it has a very restrictive license. So you can only use it for your documents and Windows, but it's still a good choice. Yeah, and as a small bonus. Also in code, we have an accessibility thing. Yeah, it's not only users, it's also programmers who can be affected by accessibility, and what can you do as a developer to make your code as accessible by as many developers as possible? Don't abbreviate is the first one. Like we as developers, we love our abbreviations, but we have to understand that not everyone is in the same mindset we are always when we write these abbreviations, and it can be very hard to read our code if we do this. Yeah, secondly, format your code consistently. An easy way to do this is to use an automated way like prettier, you just run it over your code, and your whole code gets consistently formatted. And yeah, limit the line length. Prettier also does this by default, so if you're using this, don't worry about it, but if you have very long lines, it can be hard to read if you put it on a large font size, because then you have to scroll left and right, and it's a mess. And finally, yeah, this is likely the most controversial thing I'm going to say in this talk, use tabs for indentation. I know especially Python developers love their spaces, but this is not a preference issue for some people. This is an issue of can I read this code or not. Tabs are the only way to customize indentation width, and if you either need to put your font very large or very small for some reason, the tabs can adapt. Tabs can be configured and customized, so please use tabs if you can. Yeah, and finally, I just wanted to highlight that everyone can help. This is not just a thing for developers, so please report issues. Continue to report issues. We need to know. We can't keep an overview of all of these issues, and every report helps. Also, what you can do is test for common concerns, so sometimes just try to navigate something by keyboard, even if you're not a keyboard user, and report that. It can help a ton. Yeah, and also be an advocate, like just telling people that this matters and spreading the word can also do a lot. And yeah, with these words, I'd like to close the talk that accessibility is really for all of us. Thank you so much. I think we've got time for a question while Asam will come down and get your slides ready. So a very quick question. I'll jump into the crowd if there's a question. I've got a roving mic. So what was your first reaction when you saw the state of Galaxy the first time? Was it like, this is all terrible, or was it like, yes, I can do a lot of cool things here? I'm going to be honest. Please. I didn't thought like I'd focus this hard on the front end, but I saw that there was a lot I could do and where I could help. And so when I saw Galaxy, I saw, I had this note of all the pain points I had with user experience, and that's what I... I'm still working through some of those. Yeah, I mean, much appreciated. Really, thank you very much. Please continue the discussion at the morning table. Thank you so much. Let's keep your applause rolling for Asam, please. Thank you. Thank you. This has been really a phenomenal conference so far. I really appreciate the opportunity to be here and give this talk. Thank you also to all the contributors. Today I will talk about this topic which came often several times. Why are we modernizing the UI? What are the benefits? We also heard from Leila why modernization and improvement is important. Also from Dan and when he talked about view and TypeScript, it all comes together overlapping throughout many talks. And here I will want to answer a few questions. So what is our architecture currently? How has it developed? And what can we do with it? And what did we do with it moving forward? So there are many reasons and this is an incomplete list why we modernize code. So it's a feature deployment, improving the accessibility, having instant rendering, better design, better reliability, better testing. There are many reasons. For me personally, one which always comes up is literally survival. So it's very important that Galaxy stays, but doesn't get stuck with legacy technologies and always continuously moves forward. It's really a driving factor. So we are not left behind. Let's take a look at where the client architecture came from originally. So Galaxy was incepted as with controller endpoints using Mako to generate the user interface. And Makos are a mix between Python and HTML. And they basically glue the backend to the front end. And this makes it really hard to introduce new activity and to introduce new features. Also the testing is really an issue. And nowadays we are with a more, much more conventional framework, but also at the latest state, very modern framework with fast API as it was introduced, but simply said stated it's like an API and a client reactive client framework. And the client framework submits URL requests to the backend response with JSON. So this separation in principle allows us to document and develop each of these entities individually and hopefully soon also package them individually and separately. If you look at the client map in 20205, we can see we already had significant improvement, particularly a very extensive view library. But one problem we still had last year was at the main entry points, the routers and the main structure of the panels were still using Backbone and Mako. That meant when you navigate away from one of your view components, you basically had to cycle back through the entire legacy path of outdated technologies. And fortunately nowadays with the current releases we replaced all these and have a consistent view application almost entirely. There are a couple Mako and Backbone elements left which I will explicitly mention in the next slides. But overall the entire general structure of the application is consistent with literature in the sense that there are no special cases which we only use in Galaxy. So you can read your regular documentation of these frameworks and directly get to work and add your own components. It's very nice. If we look at this modernization point from a more data driven perspective, I have plotted here the number of files and the number of lines of these different technologies of Mako's Backbone and View throughout different Galaxy releases. And what we can see is that we in 1402 started to use Backbone. And then in 1809 we started introducing View. And finally in 2209 we actually dramatically reduced the legacy technologies and we can also see the significant increase of View components over the years which we continuously added. These are some of the projects which impacted this but I won't go into those details. This is a little technical but still interesting for some maybe these are literally the handful of Mako's which we have which are remaining. Most of them, some of them will remain the first four ones will probably stay. The last three ones will just be deleted. They shouldn't be used anymore actually and the five in the center which we have to revise are mostly data set related and we are planning on integrating them into the updated version of the visualization framework. For Backbone we have these four major components and we are actively working on converting these and then finally also have these tiny pieces removed basically. So there are many benefits as I said one really impactful one is that we have instant page rendering so you don't have to reload the entire page which was previously necessary. Window locations can be copied and shared so also shows that the framework is consistent we have increased test coverage and this list could go on and on but overall it's better software management feature deployment and as I said it keeps Galaxy on track with newest technologies thanks to all of you guys and ensures its arrival and improvements. So now with this new framework everything is settled in except these non-structural makers which we also still have to remove we started to introduce new components something we didn't really do in the past we were more focused on let's renew what's there and the underlying technology without changing the user interface actually. Sometimes we made huge changes and we're hoping that no one notices but now has the time come that we adjust more and introduce new features. So for about 15 years this is how generally our user interface looked like and we loved it and it served us really well. So we also wanted to keep this going and ensure that users who are used to it are not shocked or confused by any additions we make. So we decided on a minimally invasive but still I believe impactful addition to this and basically what we did is we collapsed the tool panel and introduced a sidebar, an activity bar which is flexible. Flexible is customizable as I will show in the following slides and we haven't changed anything else on this part and you can still click on the tools and get your tool panel exactly the way it was before. So everything you know is still there but there are additional options that was a go. And in this current release it's still optional so you can go to the user preferences and enable the activity bar by toggling that switch for it to appear and here is the activity bar. Initially it starts off with a limited set of activities which you can reorder. You can also grab items from the user interface like the workflows or data sets into it and you have a context menu in which you can then select activities to be displayed. You can throw them out again or as I said reorder them so customize them however you like. It's very flexible and we are looking forward to ideas and concepts on which activities are useful for the community, what do power users want. So the flexibility and the framework is there that we can simply, in a very simple fashion, add these. And so to summarize the benefits of the activity bar it's like a customizable interface. It has dynamic highlighting so let's say you start an interactive tool then the icon will appear in your activity bar if you have opted in for this feature in this context menu activity selector basically and it will show you how many interactive tools you are running. If you have notifications coming in so overall you get also more screen of state because the tool panel is mostly collapsed or can be easier collapsed. You have the dynamic highlighting and you can customize this however you like. And I believe from a developer's point of view what I think is really exciting is that we now might have the opportunity to develop components which are only useful maybe for a subset of users because we don't have to force it onto everyone else so you can select a certain activity which maybe is only interesting for some people and this lowers the barrier to introduce new plugins basically or activities in this case. And we have as I said a storage framework for this which is really easy to register these activities and another thing I want to mention is that the entire UI is now uses the flexbox rules so previously we had if you added a component to the UI you have to maybe adjust the surroundings because we used a more global approach on it and this is not necessary anymore everything is flexbox so you can so that means every component has its own rules and its own context so you can add as many as you want or you can throw them away and the UI will adjust to it the layout will be automatically adjusted to it and this also was important for this project because we throw in this activity bar and I really would like to thank everyone it's like impressive to see how we over the years achieved this across continents different cultures and accomplished such a complex project moved so close to this completion I think it's as I said except these data set makers we actually pretty much did it and we have now the opportunity to really get input and collect input throughout from power users or any user to really identify what's needed and how can we further adjust and improve our user interface so thank you very much thank you so much great talk great great talk we've got time for a question while Cameron comes down and gets his slides ready questions Sam when all the migrations are done what is next so what is the next big thing I think there are so many features which are still needed actually I mean we saw the improvements for the workflow editor so I think there are also there's still much more we can do I think what would be the next big thing for me personally is I'm always like kind of flexible I might tell you something now and then it changes when I get more information which I believe would be more important but overall I think it would be really important to use these features now and adjust the UI simplify the UI because what we heard often from users is that the UI is too complicated that it's confusing and may we can use these tools to more domain specific and application specific adjust our UI so that's something I would like to do and then of course technically we want to view three is pretty big if you talk about these technical plugins we want to integrate you talked about plugins do you also have a vision for maybe how people can take components that we wrote and embed them on their own sort of domain specific page like for instance they want to just display parts of the Galaxy interface and like a report or something like this like web components is that a thing so we have to we are working on once all the makers are gone what we will do is package the client individually within it and then we probably break it open into several parts and so ideally someone who wants to do his own user interface can just grab some of these and build it just using view and using the API so that it's a flexible approach so it's we also had we want to add this in the past this approach that someone or people try to generate their own Galaxy user interface because ours was too complicated and they couldn't reuse those so that's something which should be ideally a thing of the past so the packaging is very important bootstrap view is very important that we get to view three actually entirely and once everything is in these compartments install the packages which ever you need if you want the tool form, if you want the workflow editor or if you don't want those and you just wonder a simpler run form and maybe use a grid or something so that everything becomes modernized in that way right thank you very much thanks again let's give a round of applause hello everyone I'm here to just share a little bit of very rudimentary work that I've been doing with the tools team in Galaxy Australia over the past six months so this is myself and Tom and Mike they're sitting over here so really we've just been tinkering around hassling the Galaxy database to try and figure out what we can do to create a tool auditing process for Galaxy so in user experience surveys that we conducted by Maddie and Mock we asked many questions including how can we improve tools on Galaxy Australia and this is the response that stood out to me the most which was fix or remove broken tools it's the first impression that people have of the service and this resonated with me because it just reminded me of a lot of personal stories that I've had with potential Galaxy users I tried to introduce them to the service and they were like yeah I gave it a try but things seem to be broken so I just got a free subscription to Genius and did my analysis on there so where are we at in Galaxy Australia we have over a thousand tools so it's an awful lot of tools to keep track of and make sure that they're behaving so I started thinking to myself how do we actually know which tools are broken like where do we know where to focus and put our attention when it comes to answering this question the best metric that we have at the moment is these user submitted Galaxy tool error reports so somebody runs a job the job's failed they click the little report a bug problem and Igor gets a message and fresh desk so we have one of these kind of things here so I just tried to corroborate this against job failures in the database so in a 60 day period we had nearly 70 of these error reports and that was matched to nearly 6000 failed jobs and these are unique error jobs that are time to explain what that is but it's it's not counting the hundreds of jobs that were run as a result of collections but it's an awful lot of jobs that turned out in the red so that's not necessarily broken tools that we're looking at a lot of these will be user errors which I'll get into later so yeah before we can start zeroing in on these tools and trying to improve them we've got to understand which tools they are and what the issues are so we go to the jobs table in Galaxy so this is part of Galaxy's database there's a record here for every job that was ever run pretty much and we can see what the tool was what the status was at the end and if there's an error job we probably have an error message as well so there's millions of rows in this database that we can go to look at and try to assess which tools are healthy and which are not and yeah there's a bunch of different ways that we can ask questions from this data for example and this is probably what we care about is the tools seen the most show me tools frequently and are popular so why do we care that they're popular if I can fix a tool that's broken for 50 users versus a tool that's used by one user it's a much bigger impact on our users per hour of my time so we don't have time to fix everything but we'll do the best that we can to improve user experience across the board so this is kind of the first step that we've taken and here we're pooling in that data from the database running it through some Python scripts and doing just a basic number crunching here so we're able to calculate error rates for tools so now we have one row per two which is reflecting hundreds of potentially failed jobs and we can then order that by error rates and the shittiest tools basically rise at the top so we have Funnand take predict here which has nearly a 60% error rate whatever is causing that it's not a great user experience for somebody obviously we need to dig into that a lot further before we can solve anything but it starts to show us where we can focus our efforts just more broadly across the service we just set an arbitrary cutoff of 25% failure rate we just call that a broken tool if you like or a troubled tool and there's nearly 20% of the tools of the popular tools on our service that are in the red here so that's an awful lot of frustrated users at the end of the service whatever the cause is so when we come to zoom into a specific tool we want to try and troubleshoot it and figure out what's wrong we don't have time to go through hundreds of error messages in the database so we want to try and figure out ways to collapse that down a little bit so we ask a question show me typical errors for this tool this is where we get a little more technical we take all these error messages try to tokenize them we try to cluster so that gives us something that looks like this so this is diamond it shows us so this is about 70 error jobs that have been collapsed down to just four different error messages we have a count for each of those errors and we can quite quickly see okay contains DNA letters taxonomy information required faster format error so these are mostly user errors this is where users put in the wrong kind of data basically and that's much faster than trying to go to the galaxy database and read through all the jobs what we got to remember even though these are user errors every error job creates a bad user experience so even if it's the user's fault the jobs failed there's still something that we can do there so if we can go through labeling these broken tools and map them onto solutions there's I think there's a way that we can improve user experience across the board so we can do that and we can do that we can do that by creating documentations and tool help text and training materials well for user errors and then tool errors fall into their own categories here that we can obviously do things about to fix them so at the end of the day this is the sort of service that we would like to see where we're only in baby sort of steps at the moment but we would like to have some kind of long-term automated monitoring so we don't have time to go and do this analysis but we can do this and we can do some of the algorithm on how we can go in and set up the and then try to fix and improve before users have to submit a ticket and maybe we can have notifications for broken tools as well especially if we just installed the tool or updated the tool it would be great to see if that's just started erroring because that's probably a technical issue and probably lots lots more based on the conversations that I've had this week itself but probably not or it might be a custom VGS or whatever front end I'm not sure yet but we will hopefully flesh that out at the co-fest. Thank you very much. Any questions? Maybe we have time or grab me tomorrow at the co-fest. And next up is Catherine talking about the history mailer. Thanks Catherine. Yep I'm going to talk about the Galaxy Australia history mailer which has been running for a few years. So a few years ago this came up that we were facing a rapidly increasing volume of user data and a lot of user data was accumulating which had not been touched for a long time. And the storage policy of Galaxy Australia is that unused data will be retained for one year. So the history mailer process was developed by Simon Gladman and Tom Cuddy and it was switched on in 2020 and has been running ever since. It's a Python script that integrates with the Galaxy API and a postal API to let users know of upcoming history deletions and to delete old user histories. And so far it's freed up over 100 terabytes of disk space. So it's a Python script. Its main modes of operation are warn, delete and purge. So warn, it will send warning emails to users. With delete it will send deletion emails to users and actually set the histories to deleted state. And purge is the final one where it will purge the deleted histories. It can also post summary data to Slack. And this is just a picture of what it's doing when it's on its warn cycle. It gathers a list of eligible histories for warning from the API and these are histories that have not been published and their update time is more than one year ago. And it groups them by user and checks the user info again from the Galaxy API. So it's looking for the user name and email to send the email and also group membership because there is a setting to have a group of users who are exempt from this process. So it will then send emails by the postal API and it stores data about the histories users and email notifications in a local database and this is really important so that when it goes through its next phase of data deletion it knows whether users have been informed by email and whether the email was sent successfully. And so now we've made the history mail code available in GitHub under the use Galaxy AU owner and you can configure things like time thresholds for the retention time for data, minimum time between warning and deleting or minimum time between deleting and purging and configure postal Slack Galaxy settings. And with the Ansible role you can configure the email templates, set up the local SQLite database and Chrome jobs. And in the future we'd like to be able to make this able to send more than one warning email at the moment it sends exactly one and it would take a little bit of work to make it send an arbitrary number. We'd like to send one say six weeks in advance and then one three weeks in advance. We'd like to accommodate more than one option of email server at the moment. We can only post it to postal. We'd like to improve the dry run features and use Byblend because at the moment it doesn't. And yeah, this was the work of Tom and Simon and thanks to Galaxy Australia team. Thank you, I think great tool and great talk. I've got time for a question while Other comes down to get your slides ready. What do you think of putting it in Galaxy itself? I Simon gave me a copy of this so many years ago and I've been trying to get around to doing exactly what you've done and fantastic but I always found it very slow to go through the API. The queries would be a lot faster if it was directly in Galaxy and you know one of the scripts in the scripts folder. I think that could really benefit a lot of admins. Yeah and we could send emails that way too. Has anyone ever ignored the email and then come back and said oh actually I need that for my thesis? One or two, says Gareth. How did that end up? Do we want that on the mic? It's probably there. So in the three years it's been running two users. One was on sabbatical for more than two weeks and they missed out. They missed out the day they went out to Officeworks and Porta Hard Drive to copy their histories to so we helped them recover those. At least the metadata and the workflows could be repeated. The other person came back five months later and said where's my data? That was off you go. A robust conversation. All right I mean maybe I can also just jump in and say I mean this is really cool, really much needed and maybe give a plug to Davy's work who's I mean he's not currently here but we will have the history archival feature in Galaxy so that will let users export data sets they don't need anymore to like a repository and then purge the history and I think this is also great sort of script piece of logic that we could potentially integrate and like have this archival feature run automatically so that maybe users will be able to recover in the worst case or like maybe that's it's another default where you say okay we push it to tape or something like this so yeah very nice stuff. Let's thank Catherine once again. All right and now the final talk in this session. Alizana, thank you. Okay so good morning everyone my name is Alireza. I'm a software engineer of the Galaxy Freiburg and in this talk I'm going to talk about the migration journey that we have from VWix to PNIA in Galaxy. So before I'm going to talk about the things let's take a quick look about what topics I'm going to talk about. At the first I'm going to tell you about what is a store in this context of the web client of Galaxy and what's the VWix limitations features has and then we will take a quick look of the important features of PNIA and then I will give you an update about the current state of migration process. So what is this what is a store in context of web client? Imagine in Galaxy we have lots of data that we need to render the components to give some information to the users. A store here are playing important rules that keeps data and create some methods and makes this data accessible to other components and also sync the data during the whole application and helps users to have the data in a blank of eye and in a synchronous way. So as we have a view in 2017 we also brought the VWix as a store manager into the Galaxy. In that time it has really good ground breaking features such as it was a centralized store. It means that all the components from Galaxy that have access to the store data it introduced the mutations and actions to modify the stores and perform complex logic on the store data and it also supports dev tools that means developers can debug and follow the way that the data goes in the store and find the problems or improve the performance and it also supports hot reloads. It means that during the development process developers doesn't need to refresh the page to get the new updates or new changes from the code but it has limitations especially for big applications like Galaxy. Again centralized is a limitation here because we have a lot of stores in Galaxy that makes a problem after a while because for example when you want to have access to a small data you have to import the big store to the application that makes a complexity and lack of memory or so and it also has some problem in performance because of this centralized and complexity and it's not built in in TypeScript that we brought in the Galaxy in the previous version and we cannot get 100% leverage of the TypeScript in our Galaxy web client. So as alternative PINIA is introduced to be a default store manager of the ViewFree and we brought the PINIA as the next store manager in Galaxy. So the outstanding features here are that there is no mutations anymore in PINIA it means that we don't have one more step it makes it simpler to access the data or modify them. It's designed by modular it means that we can have many as many as we want stores and import them as we want them in everywhere of application and it's also supports composition API it's a new way that ViewFree brings to the view and it helps to export logic from components and use it use them anywhere in the application. It's also completed type with TypeScript it means that we can have a safe and more readable more maintainable code during our development process and by using PINIA we are okay we don't need any more using providers to get access to a store during our application it makes codes readable and more more maintainable and it's it's super lightweight in compared to the ViewWix. So the current states of migration process from ViewWix to PINIA is that I as you can see these are the stores that we are using currently in Web Client. Green color represents the stores that are fully migrated to PINIA and they are leveraging the PINIA store right now but the orange ones are the stores that are not migrated to PINIA yet but I can say we migrated most important ones most important stores that are users and history bonds and they are now using the PINIA and our aim is to migrate all of them in the next version or so and also we are in this migration process we are improving our code base improving our logic to make Skelexy better and better. So before we conclude I would like to acknowledge the outstanding individuals who have contributed to this migration process and yeah and I would be happy if you have any questions that they can answer thank you. Thank you so much you've got one burning question let's have it now but we're going to have a very short stretch break that's the official term so how many minutes are we getting for a stretch break five minutes five long minutes so if any quick questions otherwise use your stretch break time to ask a question but otherwise thank you very much for that talk and thank all the speakers in the UX session please.