What?

At ARC I think it would be fair to say we strive to develop and improve not only on an individual level, but also on a group level. One of the ways we are doing this is through our RSE (Research Software Engineer) Initiatives – aiming to advance/evolve the RSE team to improve collaboration and delivery of the best possible software. They involve taking a more objective look at the current processes within our department and determining, by consensus, whether some of these processes need to be updated, or if a new solution should be devised. These are not overnight quick-fixes but rather, slow & steady progressions in the right direction.

We’ve focussed on 3 main areas: Professional Development, Best Practices and Knowledge Sharing.

As we’ve recently reached the 6 month mark of embarking on this journey, I thought I’d share an overview of each initiative’s aim and how we’re doing.

Professional Development

Notable people: Connor Aird, Stef Piatek & soon to be Paul Smith

This is about understanding how we currently decide to upskill (soft and technical) ourselves, what opportunities there are and how we can enable and support more/better opportunities.

The way we decided to figure out what people are doing regarding their professional (and to some degree personal) development was by interviewing them.

At the time of writing almost all the interviews have been completed and data gathered, being prepared for analysis.

Best Practices

Notable people: Haroon Chughtai, Kimberly Meechan & Emily Dubrovska

This looks at how much we engage with establishing and following best practices with technologies, languages and tools. We also want to determine whether there are areas where we could formalise/document this for future RSEs – a notable example is within the Python Tooling Community.

We decided it would be worth modelling the approaches of the Python Tooling Community and seeing whether there are other language/technology communities within ARC that don’t have best practice guidance but would benefit from it. This was done through a survey.

At the time of writing, the next groups of interest are Web Development and DevOps – both in the stages of requirements gathering/gaining an idea of what guidance could be documented or be built on, as well as looking into how it could best be delivered. 

Knowledge Sharing

Notable people: George Svarovsky & Amanda Ho-Lyn

This is about understanding how we currently share knowledge across the group – particularly project information – and how we can improve our current systems to be more usable and make information more accessible.

We decided to do a survey to see how people felt about how information is currently shared and also how much they actually felt they knew about different aspects. There were also some mentions of discontent about where information was posted and shared across a plethora of platforms.

At the time of writing, we have added a mini landing page to the ARC GitHub (note that you must be part of the org to see it) in an attempt to centralise relevant links to various places – this is a living thing and can be updated as necessary. We have also sent out a survey (thank you to those who took the time to complete it) and have plans to act on the results – see my post with more details about this (coming soon).

Thanks to everyone who’s been a part of this and continues to help us improve – especially to Asif who is forging the way ahead. And keep an eye out for more surveys! 😁

Why?

There are various reasons why researchers may want to include custom symbols to a font; they may want to represent a new concept or add characters from historical sources that are not available in a font yet. Being able to do so makes their work more accessible to colleagues and the public. In the cases of ancient languages, there often aren’t fonts that support these glyphs as they are still being researched and aren’t widely used outside of their respective communities. There are also arguments to be made for using custom glyphs in art and design.

How?

Figure out your glyph codes

With the Unicode standard we have the capability to facilitate this through the private use areas (PUAs) wherein we can assign codes to the custom glyphs. This provides the glyphs with a universal ID allowing them to be packaged and used more widely – this can be especially important when dealing with more than one font which may make use of the PUAs as we want to limit clashing of codes and will allow the font to be usable across different projects that may have use for the custom glyphs.

If you have an existing font and want to check if it uses some PUA codes, open the font in a charset checker and specify the Private Use Area block (you can also check for other things). If you’re free and clear, then you have no restrictions when it comes to picking the codes within the PUA block.

Draw your glyphs

You’ll need to design your glyphs with a specialist tool. Since we’re working with custom Unicode ranges in this case, that’s a specific bit of functionality to look for. I used glyphr studio which was a free online tool and it worked really well. It’s a good idea to know how many glyphs you’ll need to draw as you have to specify a range, though it can be updated. If you can work from references that will make this process much simpler. You’ll also want to spend some time getting used to the interface if you’ve not used a font designer before. With glyphr studio you define the outline points and it automatically fills in the space between. Do also remember to define a height (typically automatic) and width (not automatic) so that your glyphs will display properly.

You can fine tune the curvature, width etc of the points and once you have the basis down you can always come back to fine tune and tweak the glyphs until you’re satisfied. This is definitely the most time consuming but can be fun once you’re accustomed to the interface.

Export

Export your file as an .otf (OpenType Font) and fill out the relevant metadata as you see fit. Feel free to also keep a copy of the project file from glyphr studio but you can always edit the .otf file and it should have all the relevant data. This file can be shared and stored and can be included in projects as needed.

Including it in your project

To include your snazzy new .otf file in a web project, you can just add the file to the codebase, preferably under static/fonts. Then, you can import it into your main CSS file as follows:

To utilise it, you can implement a symbol picker (particularly helpful if the symbols don’t have a letter equivalent), add to a special character input in your text editor, or assign it as you would any other font.

Et voila!

Why?

Customising rich text editors within web apps offers significant benefits, particularly for researchers in Digital Humanities. While basic text editors fulfil essential functions, rich text editors (RTEs) can incorporate features such as rich text formatting and customisable styling, allowing for clearer and more engaging presentation of textual information. Whilst they provide greater benefits than regular text editors, you can further enhance them through customisation, which can greatly improve the user experience and effectiveness of communication. 

RTEs can be particularly useful in situations where researchers are working with sources where meaning is encoded in the visual layout. They enable researchers to communicate broader and more intricate ideas effectively. Features like embedded multimedia content (photos, videos, links), interactive elements (tables, footnotes), and collaborative editing tools (history, comments) can facilitate the expression and exploration of complex concepts within the text itself. These can also include adding functionality for symbols or text decorators not widely used – helpful with mathematics and ancient languages. See my post on creating custom font symbols for more details.

Customisation can also foster more connections and cohesiveness within the website or application. Integrated features such as cross-referencing, hyperlinking, and version control enhance the interconnectedness of textual content, enabling users to navigate seamlessly between related information and fostering a more immersive and engaging user experience. 

TLDR: Basic text editors are fine for simple input, Rich Text Editors are better for things with more variety and customising them can build on the functionality to enrich the quality of research done.

How?

This somewhat depends on the structure of your project, but most likely it will be through a CDN, npm install or directly adding the package to your codebase (in the case of JavaScript). If you have a python based project, odds are you can install through pip.

From experience…

I recommend CK Editor (4) as this has worked well through both implementations and is very stable and well-established, meaning there are many plugins already written that work with it. You can, of course, write your own for even more customised functionality! The 5th version is likely also a good option, but may require a different license. There are different degrees of customisability with CK Editor, from using their basic setups to enabling any and all plugins you can find, which makes it very adaptable to a variety of projects. You could even overhaul the entire thing if you really wanted. It uses a config.js file as default but each initialisation can also be customised on an individual basis, as well.

For example, here are two different builds of the editor:

The first is quite simple, though not the most basic and has extra functionality that isn’t immediately obvious @ mentions and image browsing. The second is more populated (more plugins enabled) and also has some entirely custom functions (the Vs and Us on the second line) for adding diacriticals through Unicode. It also has @ mentions which have been implemented with more complexity due to a greater breadth of items referenced. These were each implemented through different languages (one through Python and one through JS) and whilst the way of configuring the build was different in each project, the results are stable and reliable whilst remaining flexible.

We have also used QuillJS but this was less well established and when it updated to a new major version, the old version stopped working (not great for a research project that is almost entirely text content).

TLDR: There are tonnes of options out there and it’s not always the best idea to go for the one that is the newest and most-cutting edge, particularly if you need something reliable and easy to maintain. I think CK Editor 4 is a solid choice for the next few years since it’s stable and well established, while still being flexible and customisable to your needs.