Skip to content Skip to navigation

Johan Baath's Blog Posts

Johan Baath Posted by Johan Baath on Monday, November 30, 2015 - 8:15am

Even though it feels like I have known the SWS team for years, the truth is that I have only been here for two months. The reason it feels that way might be because of the amount of things I’ve learned from my colleagues over the past 8 weeks could be compared to an intense 4-year combined degree in Computer Science/Customer Relations/Project Management. Another reason could be that the amazing people that comprise this team make you feel at home right away.

Why is SWS so good at what they do?

Something that became clear to me after just a couple of days working here was that the SWS team doesn't just call themselves a team, they area team. When someone has a lot on their plate while others don’t, they simply help each other out. This might sound banal, but far too often people within an organization do their own thing and don't bother about helping their coworkers because “it’s not their job." The reason why SWS manages to function as a team is because everyone on the team is highly flexible: the developers help out producers with their tasks; the producers help out developers with some of their tasks; the PMs jumps in wherever they’re needed. This allows for a high-productivity team that wouldn’t be able to function as it does now if part of the team just stood by the sideline and observed the bottlenecks that slowly brings down the overall productivity.

The power of communication

Communication is the key to everything in organizations such as SWS. Without good communication the team would hit multiple brick walls everyday, but SWS rarely (never as far as I know) does. Every morning at 9.30 am the team gathers in the collaboration space for a SCRUM meeting where everyone briefs the others what is on their agenda for the day. This is a perfect opportunity for people who are blocked from doing something to bring this up to the team’s attention, and by doing so opens up the possibility to get help from someone who knows how to tackle the issue at hand.

Every Friday the team has what is called "Morning of Awesome" (Mo'A), where they sit together in the collaboration space for two hours. During MoA the team could break into small groups and work on a project together, or everyone just sits together and works on their own things and asks the rest of the team for help if needed. One particularly valuable thing with these mornings is how it strengthens the team to work together as an organism, and not as separate entities. This is especially important for teams that have many different roles but also a product that depends on how these different parts come together. 

The willingness to help others

Instead of having someone on the team taking over the tasks that you can’t do, wouldn’t it be better practice to transfer the knowledge on how to solve the problem at hand? This is something that SWS does extremely well: they block a time to go over the issue at hand, solve it together and BAAM: next time the same issue comes up you have two people that know how to deal with it. If you instead frame these issues to only let one person to deal with them, you're depending too much on having this person available all the time. 

This willingness to help others extends far beyond the boundaries of the team - they contribute to the Stanford community by writing this blog, providing a user guide and also by attending conferences where they share their experience and knowledge with other Universities. 

The importance of having fun

In addition to being a high-performing, professional team with lots of flexibility; SWS also knows the importance of having fun. There’s a fine line between ‘having fun’ and ‘just goofing around’ in the workplace, and this is where the excellent management comes into the picture. Having management that is aware of this fine line and knows how to keep the team's eye on the prize while having fun - without wasting precious time - is to me astonishing and what I believe to be one of the key components to this extremely attractive workplace.

Last words

I am extremely grateful that I had the opportunity to work with these amazing people. Even though I’ve only been here for 8 weeks I’m confident when I say that every single one of the people on the team has taught me something that I will bring with me 5,379.96 miles over the Atlantic Ocean when I go back to Sweden.

Posted in:
Johan Baath Posted by Johan Baath on Friday, October 16, 2015 - 11:54am

If you're writing CSS Injector styles to adjust the look of your Drupal site, it's easy to accidentally get what I call "CSS bleed" into the administrative experience, which can make things look pretty funky on edit screens. In this tutorial, I'll quickly explain how to avoid overriding the styles of your administration theme.

CSS Injector in a nutshell

CSS Injector is a very convenient module for making small CSS changes without having to dig into the website's code. On Stanford Sites, we use CSS Injector frequently to make tweaks (or substantial changes) to the look and feel of our websites. You can learn more about the basics how to use CSS Injector.

By default, any CSS you write will be applied throughout your site, including on administrative pages like edit screens, even if you are using a different theme for administration, which can make things look very strange for your editors.

Excluding admin pages

Because the makers of CSS Injector are pretty smart, they know that sometimes we want to make style changes for specific pages or sets of pages. This can be helpful for making exceptions in styles for special content. By adding a list of pages you want to exclude from the CSS rules the CSS injector will know to not implement these styles for the listed pages.

Example image of pages to exclude from the CSS rules

Above you can see an example screenshot for how the "Add the CSS on specific pages"-section of the CSS injector administrative page coud look like. In this example, we have decided to add the CSS styles, for a specific CSS rule, to every page except the following pages:


This means that if you - for example - have added a snippet of CSS code for applying a red footer on your entire site, this red footer will not appear while editing a node (node/*/edit), nor when you're doing other administrative tasks (admin*) on your site.

The wildcard (*) is used to cover all pages related to a path. For example, the "node/*/edit" states that the CSS rules should be excluded from all nodes while editing, no matter of the node id. In this case, the page will be exluded from the CSS rules for the path "node/15/edit" as well as for "node/potatoes/edit", since the wildcard could be anyset of characters.


I hope this post can help you prevent some unnecessary headaches as a result of not being able to target and style the desired pages on your site. The CSS injector has some powerful built-in functionalities and using those will hopefully help you bring your website to the next level of aesthetics and on the right pages (even though a rotating "Save" button in the editing mode could be quite cool sometimes).

Posted in:
Subscribe to Johan Baath's Blog Posts