General Guidelines

Code is king

The very first thing to keep in mind regarding the whole project is that ultimately, the deliverable of our users is the code. Code is king, and we are here to help developers produce code. This means, for example, if something is quicker done through code than through some clickable interface, we should just let developers code it. We shouldn’t create some feature which requires lots of clicking and figuring out how the UI works, if through code developers could do the same thing in fraction of a time.

Additionally, some users will always prefer to work in code directly. Coding experts, or people who need full code view, will pretty much always want to code, and not use helper tools which sit on top of that code, and that is absolutely fine.

Our tools are embedded at least 2 levels deep

The extensions we create are embedded in a parent application (VSC, or Wing). This means we should respect the surrounding, and create a symbiotic relationship with this first parent. Extensions should feel like they are a part of the parent, mimicking where necessary the parent’s design, and improving on it when needed.

Additionally, even the parent application sits embedded into the users’ operating system acting as the next level parent. As such, the users will be accustomed to some standards of that operating system. Drop down menus (HTML Selects), mouse pointers, typography, and more, will be best kept aligned to the user’s operating system.

Follow the local design system

As our tools are embedded in another tool, we have decided to honour the design system of the surroundings and create our tools in such a way to make the entire VS Code window look like one solid application.

There are extensions on the market which have chosen the route of their own branding, look & feel, in order to establish a visual coherency with their original brand, however, in all of the interviews we've had with SAP developers, they clearly said they'd prefer for the tool they are working with to look as a coherent single tool.

Our alternative was to use Fiori design system to design the extensions, but that would just look very strange once put into VS Code. Hence, we are mimicking Microsoft's look & feel of VS Code itself, expanding the design language where necessary while maintaining the "this is a single tool" mentality.

This is a coherent suite

All the extensions we are creating form a coherent family. As such the same design challenges should be tackled in the same way. The users should figure out how something works only once, and that same thing needs to work the same in all other locations. The whole suite needs to feel & function as if it’s a single monolithic project.

Specialise and hand-over

Each extension does its own focused task. Should one extension require the functionality which has already been designed in another extension, it’s best not to replicate the work, rather we should send the user away (or somehow leverage the work already done) to do that specific thing in the extension which was designed to solve that specific problem. Of course, some slight overlap of functionality is inevitable, we should just make sure to keep the number of overlaps as minimal as possible.