08th of Oct 2020, 01:55
While the 2020 pandemic and the resulting quarantine installed in most countries around the world is not a particularly motivating topic to talk about, if one is lucky enough to remain in good health, the choice to make to the best of your time at home is most likely a welcome opportunity to many that have found themselves chasing the white rabbit for too long. During the evenings of the past 3 months, I took it upon myself to finally confront some of the criticism I received, as well as my own minor issues I had about my website – particularly the most common one: the font is too small.
Now, back in the days when finishing the original design, I was aiming for a fixed width for reasons stated in the first Welcome blogpost, here. Therefore, simply increasing the font in the old layout did not result in any acceptable outcome. Everything had to be accommodated to suit a larger font. Also, I had some skeletons in my code I wanted to address and clean up the background a bit... as in, a lot! Simply put, I had to roll up my sleeves and get dirty, as I was about to delete code like I was pulling weeds.
Keeping it relative: resizing with rem
One of most important things I finally understood about CSS is that, while the underlying DOM still works entirely in pixels (try to retrieve any size or position of a DOM object and you're left with converting pixels to any other format you might want to compare it to), you should actually use them very sparingly as a unit when defining your style sheets.
Eventually, the modern times were bound to finally hit me with a baseball bat: 4K displays, mobile devices of all shapes and sizes or even non-screen based displays that work through sound or touch don't work well with old approaches. They all have to be accounted for in one way or another and the only way to do this the modern way is to turn to one of CSS' newly introduced units: the rem, or root element font size. Not wanting to deal with cascading font size dependencies, I opted to use rem's instead of em's, unless it absolutely made sense for a particular element's value.
For your entertainment, and to see this in action, you can test the design relativity by changing the root element's font size from a standard 16px to any size you like:
Please keep in mind, that these buttons are experimental and may break something! Just reload the page if anything was pushed out of place. I understand
Current root element font size:
At around 10px is what the old design would have looked like in comparison!
Pixels were used only in relation to a few visual elements that the design truly called for being a pixel wide no matter the root element's font size, like borders and... mostly borders, yes. No more points, though, unless I decide to make a print specific layout in the future.
One realization I had during this process is that any font just doesn't scale necessarily well. The previous main font I was using, the trusty Geneva, just didn't work that well with the bigger design. A new font had to be sought after. Unfortunately, the choice in fonts is huge and my knowledge of them is limited.
I ended up going for a collection of fonts that I think work reasonably well. For the general typeface I chose the classic, round Futura, albeit the thin edition of the font, while for the titles I used the modern, open Alata typeface. Interestingly, Futura seems to have some issues with Safari and iOS devices, which I don't fully understand. In all instances where italics or obliques needed to be used, Safari would also render the font bigger and in bold. Conversely, Chrome would hardly render any change in Futura's appearance when using the bold style, with Firefox just being marginally better.
I ended up using a third font, Lato, which seemed similar enough to Futura. Yet, it also added some freshness to the design to spice things up without creating a horrible jumble of fonts. It is primarily used in any instance where I needed to correct for styles (see image). But also, I ended up finding more suitable for the form fields and other smaller elements around the site. For example, the '+' sign to expand blog posts uses Lato, although I will eventually replace any button with SVG images instead of written characters for better consistency.
Ah yes, Flexbox, the magical word everyone has been talking about for the past 3 to 5 years. I remember Java having similar approaches back in the day, implemented in classes like BoxLayout, GroupLayout and FlowLayout. If the CSS Working Group was inspired by these old approaches or not, however is not really the point, here.
As you probably noticed, the website has a centered layout. Flexbox finally got my attention looking through the Chrome web.dev LIVE 2020 videos. There, a few tips on modern layouts were presented. Following the examples is what ultimately sparked my journey to redesign the entire website. While the grid layout solution presented in the linked video looked promising at first, I ended up not being able to make it work for my needs reverting to using a 50% left offset with half a width's worth of negative margin. Yet, I was unhappy with the interdependency of two magic numbers floating around my code (the with of the center content <div> and the offset being half of that) and I started looking for other solutions.
I started toying around with Flexbox, which also allows for easy centered alignment. What I ended up realizing is that I was putting the centered design onto the <body> element for the entire page, but I should have placed the main content into a container <div> from the start for better control. Perhaps I would have gone with the grid layout after all have I thought about this back in the beginning in July. However, I have since gotten accustomed to Flexbox and it actually has proven to be a savior to some of the other layout problems I was facing.
Having the container <div> then allowed me to include overlays, like the gallery <div>, that can live outside the container and, hence, is unaffected by, and doesn't interfere with the Flexbox model. However, the main and sub menus were proving to be a bit of a headache, since they had different widths, depending on the submenu's content, which made Flexbox adjust the center according to all three elements (left, center and right) instead of keeping the middle row centered and adjusting the menus accordingly. I was eventually able to solve this issue by introducing another container for each menu with a single pixel of width. The menu itself would then be overflowing the container, being aligned to the right (for the left, main menu) and the left, respectively.
Compatibility and Fluid Design
I design and check this website mainly on a regular laptop computer with the most common browsers at my disposal. Hence, it can be most likely be called optimized for these environments. However, another thing I always wanted to tackle is to make this website more adaptive to two target groups outside of the main one: mobile and non-JS users.
Unfortunately I heard of the phrase mobile first too late in the process of making this website. Perhaps in the future, I would take such an approach, although I would need to find a way to more comfortably and reliably test and debug for mobile devices.
However, I did come up with the non-JS first approach to web-design by myself and very quickly (although I'm by no means claiming I invented the term or am the first to use this approach!). It was clear to me, considering the opening animation of this website, that this website needed a way for people without JS enabled or browsers that do not work with JS to be able to finally and somewhat comfortably browse this website. I can comfortably say that this has (hopefully) been achieved to the fullest. All Django templates were we-written to create objects that are non-JS friendly, which are stylized by CSS to look similar to the original. In JS however, I go in and replace all these objects with their more "modern" counterparts that come with all the fancy features only JS can deliver.
Having this camp covered, I then turned to mobile users. Previously, my approach was to supply an entire subset of templates through Django, should you visit the website via a mobile device. While I have not completely abandoned this idea (mobile devices do not need to load the slimscroll code, for example, which I might work on in the future) I wanted to figure out how to create a fluid design using media queries entirely in CSS; again, taking the non-JS first approach here. Now, once space becomes too limited to show the main menu in it's entirety, I collapse the menus into expandable floating menus at the bottom and top respectively, making the entire center content area fill the available horizontal space.
Improved Media Elements
Additionally, I had to rethink my UX elements, since mobile users using touch devices interact considerably differently from mouse input users. One obvious difference is the absence of any type of hovering over elements, since touch users only scroll and click, but the finger usually does not move across the screen like a mouse to hover over elements (unless, the user is trying to do some sort of gesture).
Another itch I had to satisfy was my displeasure with the inconsistent layout portrayed in previous media elements. A major gripe was the inclusion of too many borders and solid elements, such as the audio controls, which were placed in a solid box covering an odd percentage of the displayed waveform... or the overly large play button shown in the video previews. Moreover, the gallery has scan lines running from side to side, but started seemingly in the middle of nowhere.
All this led to a entire re-write of the images, audios and videos on this site. For one, the code is much cleaner and modern, which probably does not bother anybody reading this. More importantly, though, is that gestures on audios and videos, for example, are now much more touch-friendly, by making them gesture aware. Clicking anywhere in the audio or video starts or stops the video, while swiping left or right anywhere inside the same element causes it to scroll. When opening the images pane, the left, right and exit buttons are permanently visible when using a touch device, instead of only appearing on hover.
Ok, while I'm not using actual shaders, I did beef up the design with subtle gradients here and there. Scan lines that introduce or remove content now not only appear alone, but are accompanied with glow effects. Previously, I had used pngs that I placed as backgrounds as drop shadows and glow effects around elements. This technique does not scale very well, though. So, I replaced them and added new, subtle ones in key areas to make everything look a bit more polished. For example, most media elements now have their controls not in solid bars but floating over a gradient of some sort, which can give nice animation effects when hovering or clicking.
Take a look at this example for the new audio player:
In case you didn't catch it, it is not the prominent glow from the bottom that I want to draw your attention to. The progress bar line subtly changes by reducing the amount of glow around it, giving it a subtle reaction to the increase in light as the user hovers over the element, as everything takes on a sense of focus. It is effects like these that I particularly enjoy and believe give the website an elegant touch.
Being curious during this process, I wanted to see what might have changed in JS land and if jQuery is still the status quo in this camp. Lo and behold, it is suggested that jQuery not be used for DOM-related animations anymore and other libraries were suggested. I ended up opting for GSAP, a complex library that promised vast performance improvement over both jQuery and CSS animations. In fact, the simplified code and better sequencing of complex choreographies with the introduction of timelines was an extremely helpful feature I ended up using a lot.
However, triggering small animations during user input (i.e. by clicking on a field that should make something move) has proven difficult in certain situations. I suspect the issue being that, while timelines did help simplify complex tasks, they also made simple tasks more complex. For example, if a timeline was already running and the user clicked on an element that triggered extra animations that needed to run in parallel at this exact moment could mean complex calculations of time offsets to place the new animations into the existing timeline. Things didn't alway behave they way they should and most of these issues is due to me learning the library and only going as deep as necessary to get the job done.
Additionally, working on legacy code and not entirely embracing GSAP for all things animation-related might have been a tiny mistake, as CSS animations could clash with what GSAP was trying to do. Nevertheless, it is sheer impossible to animate CSS pseudo elements via DOM manipulations (i.e. JS) and simple :hover animations feel just better placed in CSS code than in some obscure JS function. So, while I feel I definitely did gain some by doing the switch, I also feel like I completely abused the intention behind GSAP and need to dive in deeper to take full advantage of it's performance benefits.
All in all the redesign feels quite successful and I hope that it allows for a better visiting experience overall. The main issue, the larger font is definitely solved and should hopefully please most critics now. Also, the entire design is now perfectly scalable with the simple increase of the base element's font size, making it easy for anyone to increase everything should they still have issues reading any text. The website is now much friendlier towards visitors without JS and towards mobile users. Animations should hopefully feel a bit smoother, although this can still be greatly improved in the future and scaling the browser window should make the website adapt should window real-estate run low. Media players and the gallery should now work much more smoothly and be better usable with touch devices, that also don't have any hover capabilities.
I made two screenshots to compare the old and the new "side by side":
There are still a few things pending to be done. For example, background <canvas> animation art and a few other smaller features are still missing. Yet, hopefully the effort that went into improving the site can be appreciated and with a cleaned up code base in the background, I am looking forward to making even more performance improvements in the future. Cheers!
20th of May 2020, 17:50
Under the EU Project "Interfaces", funded within the "Creative Europe" program, the No Input Ensemble was invited by the ZKM in Karlsruhe, Germany to participate in a disjointed performance around the entire city. A total of four groups and artists played in different corners of the city of Karlsruhe. The performances were all joined together at the central hub at the ZKM "[...] like a kaleidoscope and artistically processed in a sound installation [...]" in the different locations around the facilities of the museum.
A CD of this performance has now been released on the record label Gruenrekorder as a single track of 62 minutes and 12 seconds. You may grab a copy of the limited release on the record label's shop here
For our performance as the No Input Ensemble in NEXT CITY SOUNDS: INTERFACES, we oriented ourselves along a concept that would base itself in a Drone-performance, as part of the performance space ambience, the ZKM-Kubus' Subspace, but would simultaneously provide fitting material for the central mix in real time. While we were not able to hear and react to what other artists around the city were doing at the time and we're confined only to our own performance, we were however able to study the collaborating artists and prepare ourselves to find our place in the overarching soundscape. The ensemble developed multifaceted spectrum of sounds that would be affected by a restrained character. However, it's detail rich and lively sounds we're able to stand on their own, as audiences we're not only able to visit the central artwork, where all performances were mixed together inside the ZKM itself, but also visit and enjoy the other performances on their own.
The No Input Enseble are Tobias Grothmann, Marnin Jahnke, Daniel Lindenkreuz, Timothy Schmele and Tobias Walter.
The other performances were by artist Lasse-Marc Riek, Lintu + Røyk and KITeratur.
Multi-room sound installation at the ZKM: Marco Kempf (Cube balcony), Benjamin Miller & Barbara Nerness (underground car park at ZKM), Sebastian Schottke & Dan Wilcox (ZKM Cube)
Production: ZKM | Hertz-Lab
Concept & artistic direction: Yannick Hofmann
Mix & Mastering: Sebastian Schottke
Software development: Dan Wilcox
The original link to the event can be found here
22nd of Sep 2019, 16:17
Smartphones might have come to save our lives from the Stone Age, but when looking beyond their devilish grin, one can grasp a sense of their true nature. I have never warmed up to them and I believe this is due to some serious design flaws and lack of focus on what is really important that diminishes the user experience. Here, I want to let off some steam and rant about my gripes with these little monsters and their creators.
One of the biggest mistakes I believe smartphones designers have done is to put too much focus on touchscreens. While they do offer some benefits, mostly the removal of an interaction layer by promising to simply reach out with your fingertip and touch the element you're interested in,  putting all your design eggs into a single basket causes a whole new bucket of problems. By this, I mean tunneling all user interaction entirely and exclusively through the touchscreen.
First of all, they have an issue with moisture. Water does not go well with most touchscreens currently built into phones on the market. Just done the dishes or washed your hands and didn't dry them with a hairdryer for at least 5 minutes? Well, good luck getting that phone unlocked or answering that important phone call. Need to use the phone to call a taxi out in the rain or check the bus schedule? Well, sorry, but that technological wonder will be too confused about what's a finger and what's a drop of rain.
I, unfortunately, have warm hands and tend to sweat more than the average user. With sweat comes grease and this means finger prints. Even worse, though, is the fact that the touchscreen may think that a finger print is type of finger extension. I have spent quite some unnecessary time throughout my experience with smartphones trying to unlock the damn thing or clicking randomly at high speeds because of the touchscreen going wild with all these ghost fingers.
The infamous butt-dial
I cannot figure out, how designers of large phone companies do not have any type of quality control procedure in place – at least one that makes any sense. Because, how otherwise would one explain the fact that the "lock" that should prevent me from accidentally tapping on my phone while it is being carried in my pants does absolutely nothing. This touches heavily on the previous topic: on the one hand it can be frustratingly hard to unlock the damn phone and accept a call while on the other, my pants are somehow incredibly skilled at this, turning on my flashlight and dialing emergency numbers nearly every week.
I understand that this was an issue back with the old brick phone, but locks used to be physical switches you'd have to flip to get anything done. Now, a swipe up or down is enough to get your phone accidentally into airplane mode and secretly preventing you from receiving any call or message until you finally remember to check.
Delicate pieces of...
Brick phones, being called like this post mortem, got their name due to their incredible durability. They had great batteries, being able to run off of a charge for a week was a selling point. Dropping it was not so much of a deal as it is today. Nokia became a legend for this... which unfortunately it has not lived up to.
Today, we have a new legend: that of the infamous spider app. Drop your phone once and it automatically downloads itself to constantly display a beautiful spider web pattern overlay on your screen. If a battery charge can last a day, people may be in awe of you for having such a powerful battery.
What gets me more, though is the delicacy with which you need to hold on to your phone. Keep in mind that this is a mobile device. Gripping it tightly is by design a huge no-no. Samsung gives you "edge-less" phones where I honestly have no idea how you would properly hold onto it without ever accidentally tapping on the sides of it. I tend to keep my pinky below my phone while holding it, but – oh dear! – I cannot unlock it with a swipe upwards or close the current app by accident because it registered the pinky as a finger at the bottom of the screen.
I do not understand why tf designers do not design the phone with it being held in a hand! If I am on a bumpy tram or bus, I am walking in a crowded space or simply in fear of it being stolen out of my hand on the metro, then I cannot grip it tightly and still use it. No. I need to balance it delicately on the flat open palm of my hand, careful not to accidentally touch anything less it is the intentional tap of my carefully placed fingertip. Or, I am to turn it off, put it in my pocket and wait until I am at home so I can place it on a velvet pillow facing upward and pray that no earthquake will make it drop and break the screen. Use it while on the go? A mobile device? I must be out of my mind. That is so eighties wishful thinking. Get real!
The horrendous car crash that are mobile operating systems
Worst of all are the operating systems (OS) of mobile phones. Now, granted I do not have a lot of experience with iOS, but I do consider it a forerunner in mobile OS design with all its fallacies, especially this isolation philosophy and approach: the user is not to be given any rights and privileges outside of those which are absolutely necessary. Having a file browser to see and delete unwanted files on your device? Unthinkable! I remember my very first argument to stay away from iPods and everything i-whatever was the fact that you could not access your music library on the mobile mp3 player by simply opening your browser and copying your files in both directions (as you could with many other makes and models at the time. Android took more than 12 years to finally include anything akin to a file browser. Previously, you had to download dodgy 3rd party app to do so. I also remember being very confused how I can delete a PDF I just downloaded by accident, because I wanted to look at some information just for a second. The viewer itself did not have a delete option!
Sharing images between apps? A nightmare! Copying and pasting text? It was not available until iOS 3.0!  I am speechless. Something so basic I would probably have run against wall would I have had to learn the hard way that I simply could not do that after spending prime money on a luxury device like an iPhone. And still, even today copy and pasting is not a given in all situations with Android. Copying a URL from your browser was not intuitive or always possible in all versions. If there is text somewhere, you are not guaranteed to be able to copy it. Why is something so basic not deeply engrained into the OS in mobile platforms? The only thing I can think of is that the focus for mobile OS design was all about user safety and idiot proofing. So we treat the users like babies who don't know anything and pad them in layers of pillow until they cannot move anymore. Simple things like copy & paste were either deemed too invasive or simply forgotten, considering that they finally included the functionality, awkward though it may be.
This invention, the on-screen keyboard, is so rage inducing, I am by far not the first to write about this. Everyone has their issues with it. Autocorrect is a meme so old that it is already dead by the time this text is written. Today, I cannot simply type. No, I need to be painfully aware of the last two words I have just written, because Android might just change them again through some obscure context sensitive algorithm. Even though I think I wrote the exact word I wanted, two words down the road it is changed again without me noticing it, because I am too focused on writing the current one correctly with this shitty little tiny keyboard.
Tiny, smaller-than-your fingertips buttons, no key spacing increasing chances for typos, no tactile feedback on a flat screen to sense buttons without looking and one finger, at most two thumb typing  did NOT make typing on a smartphone any easier. Whatever speed I gain through Swype is lost due to the aforementioned issues with autocorrect. Emoticons are now part of the autocomplete bar, causing me to have to delete it and rewrite a word every so often.
Why could we not have a physical keyboard? Enough people have yearned for it, I'm sure there would be a market for a niche product. But I believe that getting rid of the physical keyboard also constitutes considerable savings in production and material. If a phone is already equipped with a touchscreen, adding a virtual keyboard in screen comes at virtually no added cost. Furthermore, a physical keyboard also adds many more moving parts, which makes design and production more difficult. The on-screen keyboard has fewer parts that can break meaning that maintenance is much easier, making it more attractive to both the producer and the consumer.
A UX that makes you go wild!
One interesting quirk that I cannot fully understand is the conundrum of the volume and power buttons. Over the years, we have converged to an agreement that us users should only need a power button and two volume buttons. This is where the fun for product designers starts: where to place them on the device?
What most of them choose to do is distribute the power button on the right, while putting the volume buttons on the left... EXACTLY opposite of the power button. Any decently thinking human would consider that if you want to exercise a force, you will require a counter force. Thus, pressing a button needs something to provide a counter force to press against. How do we create this force? By holding the phone on the opposite edge of the one, where the button that we want to press is located. But, wait a minute, didn't we determine that there is a button also present opposite side. Oh boy, oh yes, and you shall press both!
So, again, phone designers force us to put our delicate babies into awkward positions in our hands, just so we can change the volume or turn it off, because we'd be creating heaps of screenshots constantly. See a discussion of this problem on Stackoverflow . Awkward positions mean less security holding the device in our hands, which results in the device falling. Bang! Off to the Apple store to buy a new device... again! How convenient. If only someone who is being payed good money could think of a better solution.
(Note: this part was added on 05.07.2021. I thought I had written about this issue, but it turns out I only touched on it in context of the concrete example of my Nokia 2.2. I would like to comment, that even newer smartphones from Apple do not feature the power button on the top anymore. Regarding Apple, if only the power button would have been opposite the lock switch, this issue could have been mitigated!)
Mobile data obsession and the constant fight for storage space
Apps like Google Maps are so helpful on the one hand, but so annoyingly complex anymore so that a budget phone is not able to cope with all the unnecessary features. Typing an address or name of a place prompts that autocomplete bar to pop up. Interestingly, choosing the options for then menu takes exactly the same amount of time it takes to realize your correct option is displayed and moving your finger to tap on it. The moment you want to tap on the correct address, autocomplete gets a response of the Google HQ and for some reason decides to update the list with entirely different entries, causing you choose the wrong option. This also happens with entries that are clearly marked as previous searches. Maps knows you have searched this address before and even though you just added a few more letters to the search bar that would still be valid to show this option, it decides that you couldn't possibly mean this previous search option anymore and removes it... only to show it again if you wait a few seconds, but no one tells you this in the heat of the moment.
Especially budget phones are notoriously low on memory. Having a phone with 16GB of space is not uncommon. These phones advertise that you can expand the storage with an SD card slot. But here is the kicker: for what are you expanding your storage?
Applications – not the user – get to decide if they want to run on internal storage or not. Simple messaging apps like WhatsApp require you to run on internal storage only. WhatsApp. An app that sends messages and pictures to friends and family. An app that accumulates heaps of image and video information to reside only in your internal storage...
Why do I, as a user and owner of this device not have the power to decide where to put this app? Why is there a button to move the app to external storage, just to have it greyed out on me, as though Android is dangling a carrot in front of my face and laughing? It is frustrating how by just installing a few necessary apps, I am already at less than a GB of available storage space. A few messages with gifs and images later and the phone starts complaining. Installing a new app? Sorry, I have WhatsApp installed, the SD card is virtually free but no one wants to sit at the table in the far side of the room... and I cannot make them sit there either.
Ah yes, the golden age of speech commands and our not so very helpful assistants. People must be happy with them, otherwise I cannot imagine why they are being pushed down our throats. I cannot imagine putting a corporate surveillance device into my home and I sure as hell don't understand why AI eavesdropping on every moment in my life should be a good thing. Using voice commands is awkward and weird, and only good in marginal of situations. Just because we dreamt of speaking to our devices back in the 60s does not mean we have to force this reality once the future became the present.
The concrete example: my new Nokia 2.2
The Nokia 2.2 boasted a competitive price and was advertised as "[...] something that would fit well in your pocket and be easy to use with a single hand."  Well, nice, but there are some flaws I want to point out, that make me question Juho Sarvikas' integrity as a product designer.
First of all, what is up with a slick back surface? Previously, I owned the Motorola Moto G4 with a texture on its back making it easier to hold on to and less prone to be dropped. Now, should I have slightly greasy or wet hands, should it rain, or should I have trouble holding onto my phone properly, it will slip out of my hand more easily and it will eventually download the spider app pretty soon (weren't it for the Gorilla glass, which is good, but dropping your phone due to stupid design decisions still is not good either).
Secondly, their super proud decision to add a new button to the side is good news at first. Finally someone who does not focus on the touchscreen alone anymore, yay! But, alas, the button is for activating the AI speech recognition only. I cannot reprogram it. To disable it entirely, I needed to uninstall the Google Assistant completely, which was probably a good idea anyway.
Furthermore, now the button only functions as an on-button. But I already have a button whose main functionality is to turn on the phone. Here is the ingenious problem only an idiot product designer can come up with: the new button is exactly opposite the regular on/off button. If I hold my phone in my left hand and want to turn it on, I need somewhere on the opposite side to push with my thumb and create a counter force. The only spot this can be done to keep hold of the slippery phone (see slick back above) in my hands is the opposite side of the index finger trying to push the on/off button. This, though, is the new button. The thumb engages the new button first, turning on the device, the index finger second, turning the device back off. Here I am, having to switch my phone to the other hand to create a counter force with two fingers and push with my right thumb again the right button to simply turn by damn phone on, for Pete's sake!
In the end...
The mobile phone world and I were never friends. Android, iOS... they are all enemies of the user. The user is dumb, evil and technically not the owner of their device even though they paid for it. Also, we all just want flashy features like cameras and even bigger screens that do not fit into our pockets anymore. Copy & paste? Never heard of that. I want to play pay-to-win games, yeah! Don't bother me with technical mumbo-jumbo...
Things smartphone designers ask of you:
- best not type on a keyboard; ideally you should only swipe and stare, swipe and stare...
- only follow the recommend use, don't even think about doing anything out of the ordinary
- you should place your smartphone down on a solid surface and avoid using it in mobile situations
- it is recommended to wash your hands before every use and avoid using it wet situations, like rain
- don't call anyone with it: it's not a phone anymore but an overpriced toy
- don't try to repair it, because, effectively, it is not your property, so pay us!
The mobile phone world is depressing. A bleak outlook into the future riddled with surveillance... of us being treated like idiots, and of others telling us we don't know what is best for us... and we haven't even touched on the subject of what governments are able to do with such power. Unfortunately, the smartphone is a voluntary prison. A device we chose that we cannot do without anymore. Getting off the grid feels like locking yourself into a cabin in the woods. Our lives are digital and our smartphone is the primary gateway into this world.
I wish product designers would treat the devices with the necessary respect for the lives that will be using them. One can only wish and rant... wish and rant.
 Arango, Jorge (2017) Discoverability in the Age of Touchscreens, accessed 22.09.2019 on https://uxdesign.cc/discoverability-in-the-age-of-touchscreens-125fcb392e08
 Patel, Nilay (2009) iPhone finally gets copy and paste!, accessed 22.09.2019 on https://www.engadget.com/2009/03/17/iphone-finally-gets-copy-and-paste/
 Lambie, John (2013) In an answer to 'Will physical keyboards eventually disappear from mobile phones?', accessed 22.09.2019 on https://www.quora.com/Will-physical-keyboards-eventually-disappear-from-mobile-phones
 Nokia Global Updates Youtube Channel (2019) Nokia 2.2 unboxing by Juho Sarvikas (Chief Product Officer, HMD Global), accessed 22.09.2019 on https://www.youtube.com/watch?v=_aJReg23ZVA
 Stackoverflow question: Why do many/most (Android) phones have the power button opposite the volume buttons? accessed 05.07.2021 on https://ux.stackexchange.com/questions/50716/why-do-many-most-android-phones-have-the-power-button-opposite-the-volume-butt
02nd of Oct 2018, 00:50
I just recently came back from vacation and in my boredom on the flights over the Atlantic Ocean I wrote a short text on drink combos for split decisions on airplanes. Even though this is not the most serious article I felt like I wanted to share it. I hope this bridges the gap I have left of not tending to my website very well.
Having flown my fair share within Europe, attendants have often caught me on the wrong foot with me having to make split decisions on which drink to choose. Hence, I have developed a system of drink combinations that I can quickly take advantage of, depending on the time of day, my current mood and choice of sandwich provided.
Flying tourist class with normal carriers in Europe usually gives you free complimentary drinks and snacks. Unlike the choice of snack, which usually comprises one of two sandwiches, the choices in drink are usually a much more plentiful. If you book with a non-low-cost airline, you may usually choose more than one drink as well. For example, Lufthansa flight attendants even encourage choosing two drinks, asking passengers if they would like some coffee or tea with their first choice.
Here are some of my common combos for split decisions and their reasonings.
The classic breakfast:
Orange juice and coffee
Flights scheduled early in the morning often mean I might not have had the time to enjoy a proper breakfast. The tiredness kicks back in after running to the airport in a hurry because I most likely timed my arrival without margin to maximize my time in bed. This calls for vitamins, hydration and caffeine. Not that orange juice served on the plane is as good as fresh pressed, but at least its strong orange taste can counter the hard hitting airplane coffee.
The tiny morning spa:
Apple juice and black tea
Airplane coffee, like many cheap roasts, have a tendency to activate my bowel movement rather effectively. Particularly if I hadn’t had the chance to visit the bathroom before traveling, choosing that cup of airplane coffee should be seriously reconsidered. Fortunately, there is another drink providing caffeine but with the exact opposite effect: black tea. Coupled with a cup of apple juice, this combo can at least give you a hint of wellness and comfort in economy class.
The full menu:
Tomato juice and coffee with cream
If everything revolves around the meal, you make it a three course one. Tomato juice in airplanes is something I never understood as a child, but once the thought hit me that it basically is nothing more than cold tomato soup my view on the whole issue suddenly changed. Tomato juice is usually as thick as a Spanish gazpacho and you will be asked if you like salt and pepper with yours - which you should accept! Eat your sandwich after the soup and finish the meal off with a desert coffee. I usually ask for cream and sugar to give it that sweet desert twist.
The thirsty traveler (Lufthansa special):
Alcohol free beer and tomato juice or tea.
Every major airline usually offers some special that represents the country they are from. ANA from Japan offers sake, Portuguese TAP (used to) offer port wine and Lufthansa gives you beer – in glass bottles! Not only is the beer stored in neutral glass, but every passenger receives the full 0.33l bottle, which is about three regular airplane cups worth of liquid. Instead of the regular alcoholic version, I recommend the alcohol free one as it is much more effective in quenching the thirst. Depending if I want to drink the beer before or after my accompanying drink, I either order a tea for after or a tomato juice as a appetizer.
The caffeine push-up:
Cola and coffee
Incredibly, airplanes can make good offices with little distractions. Unfortunately, the constant noise drone of the engines and air vents has a soothing effect that something can almost magically make me fall asleep. Not rarely have I slept through an entire 2h flight from even before we took off waking up just with the rough hit of the wheels back on the ground. If work is crucial for this flight, I go for the extreme to give me that extra attention push and one of the oldest combos in my book: cola and coffee.
The I’m sick mom:
Two black teas with extra lemon
Sometimes traveling when sick is unavoidable. This is probably the least favorable time to inhale the dry air coming out the cabin vents. This calls for something to soothe the throat. Of course its best to try and get the tea as warm as possible and simply inhale the first steam before it cooled down enough to drink. Ask for extra lemon slices and either push them into the tea with your stirring stick or fish them out and bit into them directly.
There are probably a few more combinations I might have used in the past, but these are the principal ones I can come up with while writing this article at the moment. Instead of being overwhelmed of choices when torn out of sleep, decisions can be made much more easily. Having these at hand also helps me mix-and-match and eases extrapolating on them if necessary the thirsty-traveler combo above being one example.
One additional tip on the Lufthansa sandwich: the flight attendants will usually arrive asking if you want one of the other sandwich type, defined by its principal ingredient: chicken, ham, salami, pastrami or cheese, to mention a few. Keep in mind though, that in my experience a cheese sandwich not always has the same sauce or toppings on every flight. Even the type of bread can change, with brezel-type dough being used for some, once in a while. Personally the combination of the whole sandwich is more important to me that simply the main ingredient, so I can recommend asking the flight attendants if they can tell you what each sandwich comes with. There is also no shame in asking them to perhaps quickly show you each one for a quick glance.
26th of Jun 2018, 11:06
In the upcoming weeks, I will be giving some presentations on different topics in a small tour around Europe.
First, a workshop in 3D audio production tools will be held at the 2018 Sónar Festival in Barcelona, Spain together with my colleges at Sfëar. Participants will given the chance to try out our newest beta version of our software and we will guide them through the available tools and production techniques that can be achieved with these.
Next, I will go to the Sounds in Space conference at the University of Derby in England to give a talk about both my Spherical Glitch Study I and II. The talk will center around the ideas that went into those compositions and how they are composed. It will also, however, go into some implementation details about the code, as they intersect with topics the currently running Binci EU funded project, where we are developing a spatial synthesizer that produces sound synthesis solely from spatial manipulations. The Spherical Glitch Studies provide both an inspirational ground as well as a first creative use case for this technology.
Finally, I will head to my home university at the University of Music Karlsruhe in Germany to attend the Music and Sonic Arts (MuSA) conference hosted there. There, I will give a talk on the intersection point between contemporary dance notation and spatialized music composition. This talk will present work in progress and is meant to open and inspire a discussion around this topic. Dance has long worked with the semantics of space in a compositional context and looking at the literature available and the notations developed can bring some great insight and new angles when applied spatial composition techniques. Furthermore, this talk will also go into the limitations of this comparison. While both art forms share the focus on external space as a ground artistic expression, the phenomenological shape and form of the object that is actually moving is drastically different: while one is the human body, the other is the abstract sound, reproduced from a virtual representation, seemingly floating in mid air with no apparent real world body that is producing it (if one considers that the reproducing loudspeakers are perceptually sufficiently transparent.
After a short break I will head to the AES special conference on spatial audio in Tokyo, Japan to present two papers. One on a new method for apparent spatial extent using decorrelation methods in the ambisonics domain. The other talk will be closely related to the one given at MuSA, but the focus will lie more closely on the Choreographer tool developed during the Binci project. The Choreographer is designed to stimulate a thinking of movements in terms of entities, which as such can be used as building blocks for composition and interpretation. By solidifying a movement as an elementary block of composition, it could slowly be established as an cultural icon that can be recognized and related to. The choreographer then provides higher level manipulation parameters, such as intention or force of a movement that either emphasizes or weakens a vector of direction, or simply rotation parameters that enable the composer or interpreter to turn a movement as a unit into a different direction.
11th of Jan 2018, 23:28
This Saturday the 12th of January I will be giving two presentations on spatial audio for the Tupper Festival in Barcelona, Spain. They will be at 10:00 and 12:00 respectively and last for roughly two hours. Together with Gerrard Erruz we will introduce audio producers, musicians and other that may be interested into the basics of what constitutes 3D Audio. The talks will be held in Sfëar's Barcelona studio premises in Spanish with limited availability, so if you're interested act soon!
For my own part, I will give an overview of the common technologies, grouping them into channel based (5.1 to 22.2), scene based (Ambisonics) and object based (VBAP and WFS). Care will be taken to point out the strengths and flaws in each so the participants will better learn to choose the right one for their specific purposes. Additionally, we will compare VBAP and several orders of Ambisonics with one another and learn what the qualitative differences there are. Finally, we will look into commercial solutions available on the market, now having learned the backgrounds of what they claim to be based on.
For the second part, Gerard will introduce the participants into the simulation of 3D audio over headphones, commonly referred to as binaural. Since we humans hear with only two ears, the ability to hear spatially in all directions has to somehow be possible with seemingly limited apparatus. The secret lies in both the spatial distance on each side of the head and primarily in the shape of the outer ear, the pinnae. By measuring the effects produced by the pinnae and reproducing them, we can simulate sound arriving at the listener from any direction.
Together, this two hour presentation should give a good overview of the current trend that is 3D audio. With companies like Dolby investing in this area and cinema in general pushing towards more immersion continuously, it has been shown that interest in this field has grown heavily in the last couple of years. We hope to give an insight in what these technologies and methods require and what they provide.
31st of Dec 2017, 16:44
I was able to use the time during the holidays to finally bring a new update to my website, which was long due. Just in time for new years, I would like to present my first snippet of code, written for Max/MSP. It is a small package consisting of two tools for circular interpolation. The impatient may download the package going to its proper page here.
Circular interpolation is not necessarily as easy as it sounds. I want to find the shortest way around a circle given two values: the old value I am currently at and the new one I want to go to. There are easy examples, in where I simply would go from, e.g. 0˚ to 90˚ by crossing the 45˚ mark. Easy enough, we simply use a "straight line" and move along all numbers between 0 and 90.
But upon further inspection, I notice that I do not necessarily want to go from 0˚ to 350˚ going over the 180˚ mark. Rather, I'd simply like to move from 0˚ backwards along the circle to traverse 355˚ and arrive at 350˚. Similarly, I would like to reach 185˚ from 0˚ moving backwards past 350˚, and not forwards, traversing 180˚.
Choosing the shortest path along a circle is not necessarily trivial. It requires deciding correctly in which direction along the circle to move given any arbitrary points within the interval [0,360[. You may find a detailed description of my solution along with the necessary code in the codes section, under Max/MSP, or directly by clicking here. The code can be used freely in any project as long as proper credit is given.
The package as it is at the point of writing this entry includes two sub-patches for circular interpolation and random circular walks. One nice little feature the circular interpolator has is that the user may choose what to do in ill-defined moments. A circular interpolation is somewhat ill-defined if the new value that one wants to interpolate to lies exactly 180˚ apart from the old one. Technically, both clockwise and counter-clockwise movements are valid. Yet, we have to choose one. The formulas used here automatically make the interpolation go counter-clockwise. Yet, if the user does not want this behavior, they may choose to flip this behavior to interpolate clockwise instead at any given moment during runtime.
15th of Jul 2017, 13:56
I am excited to announce that the No Input Ensemble will be playing a series of concerts in the upcoming months!
On the 15th of July, we will perform at the Hafenkirche in Mannheim, organized by elektrosmog. This will be an exclusive No Input Ensemble concert, where we will be performing some compositions and an improvisation.
Next up is the Und 9 festival in Karlsruhe. We will be performing on Thursday the 20th of July in a series of concerts during the opening Vernisage.
Finally, we are happy to be invited to perform alongside two other acts at one evening of a concert series by Post Post in Düsseldorf on the 23rd of August.
01st of Jun 2017, 23:24
So, here it is, after more than 7 years in the making: my portfolio website. Not, that it took me 7 full years to make it, of course... it was just... well, I was busy, you know? 7 years of on and off: working a bit on it, letting it sit for half a year, picking it up again, getting distracted for another... and so on. I have to admit, my priorities were more on doing my work than presenting it, hence, that is why, instead of working on making this website, I focused on doing the content that would eventually be presented here.
Luckily, all things come to an end and here it is... and I am proud of how it turned out! It is my own creation and by that I mean, I own everything and made almost all the stuff here myself. Because, not only should the content by displayed on a shiny background, but the display itself should also be something I would want my profile to demonstrate. You see, as a programmer, I wanted not only to show I can find and use existing libraries, but I wanted to take the opportunity during my free time to understand how these processes work.
Let's talk about the layout choices I made. You might have noticed that this website is quite slim and perhaps this might seem strange to you. Unlike many other websites and blogs these days, this layout was deliberately chosen not just to try and be something different, but also because a slim layout makes reading easier on the eye (see Typographie by Emil Ruder or click here). I have to admit, I took inspiration of how newspapers and magazines are traditionally organized in slim columns. The layout of this website should have little over 50 characters per line: a reference at the lower end of the spectrum. The relatively small font is a personal choice and, admittedly, might seem contradictory to the readability. But simply using a larger font did not match my design and, to be frank, I find its size quite comfortable, so there is that...
Not much color has been used, because the website should function as a clean slate, or blackboard, on which anything may be written or drawn. Even though no layout can be 100% neutral, at least black and white has a certain elegance to it and I could simply not justify any arbitrary choice of color. Besides, I do believe any color would taint your impression of the things presented here. Let the music, texts and pictures speak for themselves! But, of course, this could also appear boring, so here is the kicker: while you are reading this first entry, graphics most likely have started to appear in the background. This is my humble approach to not just making this site a blackboard to write on, but a canvas for algorithmic art. I am thinking of adding new algorithms to the background and make this a little art project of its own: little subtleties that do not distract, but once you notice them, you should hopefully be pleasantly surprised.
So why does this webpage exist in the first place? First and foremost, I want to present my work in a space owned, made and designed entirely by myself. Giving my creations to companies like Soundcloud, Instagram or – in my eyes, even worse – Facebook is not in my best interest. I do understand the benefits of using these platforms, like the communities, security, time saver, but owning instead of renting is just such a better feeling. Also, I will continue to use other platforms as I deem them viable and valuable to my interests respectively. You should not put all your eggs in basket, is what they say...
Over time, this website will be populated with my music, my projects and my research. I want to present my compositions, give explanations to them and allow previews for the interested. For my research, I want to publish summaries of the books and topics I am reading or have read over the years. Through the essays that will be published here, I want to try and provide an entry for other researchers and the interested into some German literature that might not exist as a translation out there. Moreover, writing these essays will motivate me to accelerate my own research and finish my PhD! Of course, I recommend using my texts only as an aid and remember that what I publish here is not necessarily peer reviewed.
Furthermore, I have accumulated many scripts and code that I longed to share with the world for some time now. Especially audio algorithms and patches written in Max/MSP have piled up on my hard drive and I am sure some of them could be very helpful for others. But I also want to publish and write about other algorithms, also related to this website: how to create animations like the one in the background, or how to automatically generate thumbnails that are cropped out of the original.
This website should primarily present my work as a professional researcher, programmer and musician. But, additionally, I want to present photos and other hobbies. This website is going to be my little space with my little creations for the big world to see. If you have any questions or comments, you may contact me and get in touch whenever you want.
Thanks for dropping by...
So, welcome to my portfolio! I hope you like what you see and hear and I hope this opens doors to get in touch with more people of similar interests. If this website and my work inspire just a single person to do something greater, I can count myself a lucky person.