Feedback Needed: Standardized UI SVGs
  • So Taylor and I have been talking a lot about the UI for Audulus. One of the main complaints the more traditional crowd has is that Audulus is very "toy-like." Although I personally really enjoy the look of Audulus as it is (especially with @robertsyrett and @stschoen's SVG contributions) we're planning on hiring a professional graphic designer to create a set of SVGs for Audulus 4 that will cover as much ground as possible and yet adhere to some new, yet-to-be-defined standards.

    What we want to get away from is the super high contrast colorful look and do something more subdued (see perhaps the grey tones of the Speaker and Mic nodes).

    Quite possibly in Audulus 4 we'll have two modes - a light and dark mode. The light mode would have a white-ish background, and dark might be more "traditional."

    In any case, what I'm asking for in this post is both simple and complex: A list of all the SVGs we'd need to cover (most of) our bases for almost every use, with icons that are specific (mean only one or two things) but that are immediately understood without needing to look at the manual.

    @stschoen has come up with some really innovative and great designs, and this is in no way trying to say that his creations are "not enough." However, we have the potential of working with one of the greatest synth graphic designers. I don't want to name them because we haven't yet approached them about this project, but you have seen their stuff everywhere.

    This would *certainly* not preclude the use of user SVGs, and we'd in fact still include them in updated libraries - all of the things @stschoen and @robertsyrett or anyone else has created can possibly be included in the library, so you have a lot of choice.

    But what we want to do is create a built-in library that has these super high end graphics that really create the new look of Audulus 4.

    This is a long preamble to say that we need a list of all the potential icons for controls that are shared across modules. Mix, cutoff, ADSR, etc. Keep in mind that sampling and more DAW-like stuff will also be available in Audulus 4, so we need transport buttons, sampling icons, record, etc.

    It would be a huge help if you can come up with ideas for controls that both be specific and general. The way the graphic design is right now for things like the LFO is that the waveshape illustrates what the module does, but also indicates the frequency knob. This doesn't have to be the only way it is - we're open to change. It's just what seemed to make sense to me.

    We're willing to change this stuff, but we'd like to have your input before changing it. Also welcome in this thread are general UI improvement suggestions. We want to make the perfect Audulus that you want to use, and this is one of those opportunities to chime in and really make a difference in its future.
  • I would certainly be in favor of some professional graphic design. I was happy to contribute, but I have no illusions about my skill as an artist. In the limited space available it’s difficult to design an icon that is both meaningful and visually appealing. Personally I find Audulus’s minimalist design appealing but I’m open to something new. I’ll put together a list with my suggestions as soon as I get a chance.
  • By all means work with talent if it is available. While I am a visual artist by trade, I certainly recognize that vector graphics is not my strong suite. I'm more of a paper and pencil kind of guy. I do think it is important to keep a coherent visual language and let form follow functions. For example, when visually updating Audulus, the ADSR should display a linear envelope when it is a linear envelope. Library icons can have some variability but should be of fixed size proportional to common nodes, so a given icon can be scaled fit on top of an input or a knob without messing up the autolignment that is present when editing the UI of a module.

    The UX of importing your own SVG could use some considerable improvement. I hope that in the future Audulus is a lot less picky about which SVGs it will accept and follow the same fill algorithms as adobe illustrator, since that's such a ubiquitous tool. Another workflow upgrade would be the ability to scale the SVG once it has been placed in Audulus. I have tapered off my use of SVGs mostly because of the process of having to estimate the size they need to be, having be wrong, and repetitively exporting the visual element until it fits.

    I am pretty agnostic about color schemes and light vs dark as that isn't really something I see anymore. I just hope whatever direction you go in, you keep the information that the flashing cords convey as they are really handy for debugging.
  • I think it could be an absolute mistake to change the graphics too much in Audulus. How are the graphics "toy like?" My iPad looks like the control panel for a spaceship. I think that the best thing to do is improve the graphics by balancing minimalism with functionality, while retaining the distinctive, stunning, bright on black brand identity.

    I realize Taylor works in the graphics industry, so it is natural to want to tinker. Just be careful and if anything consider a 3d plane. Then at some point we could all put on goggles and climb inside a patch.

    I think that with the advent of AUv3 some consideration will have to go into, perhaps, a way to export a patch into a locked patch panel -- but maybe not.
  • >My iPad looks like the control panel for a spaceship.
    >Then at some point we could all put on goggles and climb inside a patch.

    All aboard the mothership!

  • The move to incorporate SVG graphics over this last year has really been a good move towards making Audulus more accessible as every red and blue circle looks the same, as do green, blue, and red flashing lights. If one were color blind, Audulus would be much harder to make sense of.

    The RGB color scheme is there for a reason, the mixing of colors parallels the mixing of audio signals at all levels of the app. The rate of flashing and the changing of the colors provide information as does the general left to right time line approach with vias mixed in to provide feedback loops.

    I think the biggest issues with Audulus are a need to create a much better process for GUI design of modules. A lot of time is spent playing hide and go seek with the different layers of elements and trying to distinguish between identical looking icons by switching back and forth between the GUI level and the sub patch level. This is what makes Audulus a toy for me because it’s such a bottleneck to creativity. Compounding this problem is there’s no easy way to snap lines and nodes to grids so lines nodes, icons, lights, and text can all line up at the same XY coordinate. Once again trying to arrange items involves a lot of fiddling around along with work arounds for determining how visual elements should be layered (e.g. cut/paste text/icons/lights).

    Not being able to more easily manage which control components of sub patches should be exposed in the GUI contributes to Audulus being toy like rather than work like.

    Trying to play a patch without a more functional lock mode on iOS contributes to Audulus being more of a toy than a productive tool because you can easily disconnect/change controls which have nothing to do with playing the patch. For this reason, I always copy a new patch before I open it just so that if some accident should happen, I can copy the original to see how things were connected rather than fumbling around trying to figure out what’s going on in a patch I know nothing about.

    Being on iOS and not having multitouch control after you’re on version 3 going to 4 of Audulus? Toy.

    Would I like more professional and standardized graphics for icons. Yes so long as there is some sort of coherent color scheme to them in a themes/skins sort of way so that the logic and utility of color theory/audio/math/timeline flow is preserved. It’s great to have a visual programming environment where minimal text is needed. Ideally the international languages of math, audio processing, color, and design icon theory would enhance what Audulus has going for it.

    There should really be more of an attempt to recognize there are different types of people with their own POV/needs who could use Audulus. If the market for Audulus is to ever expand beyond programmers/engineers, there needs to be more thought put into how people who are primarily interested in easily connecting and using modules created by other people without needing to know much if anything about programming themselves.

    To facilitate the needs of programmers and players (we can be both at various stages of patch development) there needs to be more thought put into separating the activity of programming from the playing of a patch from the process of connecting playable patches together. Currently programmer considerations get in the way of the playability of patches especially on iOS. The end user should be able to customize the look/feel of the patches they’re playing to suit their needs/esthetics without needing to know or interfere with the underlying functionality that went into creating the patch.

    The programmer doesn’t need a bunch of fancy graphics if they don’t contribute to making programming easier. More monotone color schemes because the current color scheme of Audulus are perceived as too childlike due to the primary colors involved reminds them too much of their childhood or children and their toys is an appeal to superficiality which can be more adequately and appropriately addressed at the player GUI level.

    When playing an instrument/patch the final design/function has been created. The player could care less about the innards of the patch anymore than they would be in taking apart their Moog synth before playing it. Instruments can essentially be black boxes to the player so long as it meets their playability needs. The player has no need for adherence to programming color coding standards and shouldn’t be limited by them. If the player wants to have the virtual equivalent of a see through instrument with lots of wires and flashing lights, there’s a price to pay in terms of the device processing the visual at the expense of resources which could be going to processing audio. Ultimately the user should have some flexibility over this trade off. There have certainly been many music creation apps which provide users with the option to turn off automations to improve audio performance.

    Form should follow function.
  • I would second Paulinko's comments. Honestly, while I'm open to updates to the look of Audulus, I really think that they should be low on the priority list compared to some of the other forthcoming improvements. While I don't personally use Audulus on a Windows based platform, it is still the predominant O/S and in my view bringing the Windows release up to parity with iOS and macOS should probably be the first order of business followed by an update to the plug-ins. It's clear from comments on the the Forum that Windows users feel abandoned and that many Audulus users are very interested in using it as a plug-in module but are limited by the lack of multichannel I/O and MIDI support. In terms of the UI I would personally find multi-touch, some type of snap-to grid and the ability to expose a module's UI far more significant than a change to the graphics. At the end of the day it's about the sound, and I believe that improving the performance and flexibility is more important than the look. One of the things I find most appealing about Audulus is that it doesn't try to be a digital copy of a piece of hardware and I think the current UI design conveys that message very well.
  • Speaking of graphics, would be nice to have a low cpu mode (see the crackling issue on iOS at least, perhaps a performance mode?, see later).
    As far as SVG are concerned, you may need to use a more complex library that would include transparency, shadows, gradients, etc. if you want to open up the way to other looks for Audulus.
    It would be also nice to have the possibility to change the gfx of the knobs for example.
    Finally, I think the UI is not enough performance oriented. It's designed for patching, but not performing. There should be a mode with multitouch support, and where you don't move everything everywhere when you just want to tweak a knob ;).
  • "Speaking of graphics, would be nice to have a low cpu mode (see the crackling issue on iOS at least, perhaps a performance mode?, see later)."

    I second this notion! Also think the idea of customizing your knob or button/trigger color would be really fun when creating custom UIs.
  • +1 CPU is so key with synth modulation, especially heading towards AUv3 on iPad.