Koos Looijesteijn

Berlin Joined over 1 year ago

  • 14 stories
  • 70 comments
  • 35 upvotes
  • Posted to How Do You Abbreviate "Yesterday" in Your Designs?, Mar 13, 2019

    To me they’re all confusing! Perhaps something like ‘12h ago?’

    3 points
  • Posted to As a UI designer, I want to start writing. But where do I start?, in reply to Alex Camp , Jan 31, 2019

    You’re welcome!

    0 points
  • Posted to As a UI designer, I want to start writing. But where do I start?, Jan 26, 2019

    Hi Alex, what do you want to actieve with your writing? If it’s content marketing, if makes sense to write to the interests of your target group. I write mainly for myself and to just share whatever I’ve learned recently. The for myself part works best when I publish it in some form, because it makes me more careful to check sources, see the other side of things and it forces me to be precise in my writing and thus thinking.

    As for topics I’d like designers to write about: less about tools and outcomes, more about ethics, collaboration, future visions, inclusiveness, design as a profession, aesthetics and applied behavior psychology.

    For my own writing I use my notes app to collect ideas. I let them sit there for a while and whenever I have time, I go through them and pick one that I believe I can write something about from a perspective I haven’t seen before.

    1 point
  • Posted to Ask DN: I'd like your feedback on a bottom navbar proof-of-concept, Jan 19, 2019

    I think the usefulness of the concept depends on the application and users, so I’d try to do a bunch of tests with actual people.

    My impression: 1. If the tabs look like tabs I guess they’re familiar enough. Right now they look like actions, the plus button in the center adds to that. 2. I find it counterintuitive to scroll up to get the bottom nav.

    I like the creativity in the solution to work around that awful iOS Safari behavior. I don’t think it solves the problem you’re stating though. In the initial solution with the standard bottom nav, they’re a clear indication for users where to tap. In your new solution there isn’t. Another problem you had with the initial solution was that there are two actions necessary that aren’t 100% intuitive, because the buttons jump. With the new solutions you haven’t really solved that: it still requires 2 actions and the behavior of the nav appearing and disappearing is likely less predictable as it’s not standard iOS Safari behavior.

    But that’s just me.

    0 points
  • Posted to Designers for Open Source?, in reply to Varun Arora , Jan 15, 2019

    Yes, keep that optimism; I love the idea!

    Are you saying we are missing the point here and that what we need to do instead is educate open-source design leaders about the value and techniques of design and product leadership?

    Not really, I think your original idea can work out really well. It's just that I think to make the designs successful, the project's scope should go beyond having designers design things.

    Keep us posted, alright!

    0 points
  • Posted to Designers for Open Source?, in reply to Ryan Gorley , Jan 15, 2019

    You're right, I should have written "there are no FOSS screen design applications". Sure, there are graphics applications, but those require that old school workflow. I think for many projects Figma can be a great solution though!

    0 points
  • Posted to Manrope 2.0 Typeface, in reply to Mikk Martin , Jan 14, 2019

    I'd expect that to be at Menu Sketch> View> Show Fonts > Gear Icon > Typography

    Edit: nah can't find it either.

    0 points
  • Posted to Designers for Open Source?, Jan 10, 2019

    Hi Varun, I very much agree there is a problem. Free, open source software can have many benefits over commercial software (like no vendor lock-in, resilience, no commercial interests opposing user interests, customizability). It seems like such a waste that all that engineering effort is currently not finding its way to others than programmers. I haven't found free, open source software (FOSS) that:

    1. Has a UI for end-users (is not a library, CLI, etc. to make other software with) and
    2. Offers a UI and UX better or on par with commercial offerings and
    3. Is maintained by a volunteering community

    The few successful FOSS projects targeting end users are Firefox, Thunderbird and VLC (and arguably Atom Text and Ubuntu), but these have strong professional teams leading them. I'm sure I missed a few more examples, but you get the point.

    A while ago, I wanted to contribute to the software I thought could be useful to me. I felt rather discouraged after joining several bug trackers and forums though. Back then I made some notes that I just quickly put together, because they seem relevant. Feel free to skip to the conclusion!

    Why I think FOSS is badly designed

    Tools

    FOSS projects are often organised version control and bug trackers. People who don't program software typically aren't capable of using version control. Git seems to be the default nowadays and I think that's a good thing. But without some serious effort to learn and practice, Git is just horrible.

    I've encountered several bug tracking applications and I found non of them inviting. I understand it's useful to put up a barrier and not have a project flood with tickets from users. But this selects for tech-savvy users only submitting bugs. None of the bug trackers showed me what the process of submitting a ticket would be like and what would happen to it.

    There are no FOSS design applications. This is a problem, because for many projects it's important that there's no vendor lock in, specs are accessible beyond the duration of someone's paid software subscription for something like Sketch Cloud and that the tools work on Mac, Windows and Linux. Figma and Abstract offerings are a step into the right direction though!

    Organization

    For some applications, I would have liked to spend some time on redesigning features, but it was totally unclear who was running the project. Especially unclear was who could look after my design getting implemented (or who I should get in touch with about that). Even in well-organized product teams designers sometimes struggle to convince others their designs should be implemented, so I think this is a big problem.

    Process

    Community-driven FOSS projects typically have a development process that is optimized for engineers. That means that other users are rarely heard. Prioritization of tickets is based on the engineers interest in an issue. As a result, big projects lack focus and consistency in design.

    Even when submitting a usability issue in itself isn't hard (not a given), the process that follows can be ineffective. It was expected that I came with clearly specified solutions. Fair enough, you can expect that from a product professional, but not from a any user. My tickets that didn’t include solutions (I didn’t redesign all the apps I submitted issues for) were usually closed. The same happened to issues for which I provided clear solutions, as they were considered not engineering problems.

    FOSS is badly designed because it's badly designed

    Knowing the UX of better tools and designers being especially susceptible to good UI, most FOSS just looks repulsive. So designers may be even less likely to use FOSS than the general public, as Sacha pointed out.

    FOSS looking as bad as it does could be a nice challenge to make a difference, but software that is developed far enough to be useful requires such an amount of redesign work, that it would require a huge design investment. Just polishing up the visual design or making the interactions of a certain flow work well won't make it a good application.

    A designer being interested in doing that nonetheless, must wonder: "Why is the application so badly designed? Surely because the makers don't value design?" Again a reason not to even contact the team.

    Conclusion

    Bug fixes and the engineering of new features show immediate results and (possibly) measurable, objective improvements. Engineers can create their own forks and use those enhancements even if they're not accepted by the community.

    Management, design and marketing on the other hand, require collaboration, vision and often need several months of work to be of any use at all. When at the start of, say, a redesign project there is complete uncertainty about the commitment of engineers to implement the new design, it's not attractive to spend several months of work on it. This is more than a hypothetical problem. I know someone who, after several years of doing design work, left the Gimp project because of that.

    To be successful beyond a group of scratch-your-own-itch software makers, community-driven FOSS projects need more than open tools and a transparent, user-centered design process. From the an early stage, designers, PMs, marketing and business people should be part of the leadership team, not just engineers.

    Answer to Varun's question

    So as for your 'Summer of Design' idea, Varun, I think it can work under a few conditions. I think the developer community of a project must be motivated to implement the design work. When that community has been volunteers in the past, that probably means your 'Summer of Design' should be integrated with a Summer of Code-like event. An existing community may not like the sudden changes in the design (imagine having spent years contributing to an image editor to make it work for your arcane editing flow and then some design students saying it's not user-friendly).

    Alternatively, there may be projects that are not of the scratch-your-own-itch kind that still have passionate engineers. I can imagine applications with social impact as a main driver, solving problems of medical professionals, undereducated users or an otherwise disadvantaged target group. For such a product designers and others are all the more relevant to engineers, as there won't be the kind of direct user feedback they'd see in other FOSS projects.

    As you mentioned, there needs to be coordination, which, I think, means it takes the power of decision making (about product vision, feature prioritization, etc.) away from an existing community. Forking existing projects or starting completely new projects may be a way to avoid the community getting upset. Finally, as I mentioned above, that coordination (management) needs to be permanent for the work not to get derailed by featuritis. All in all that would mean you'd be putting a professional product team together to lead such a FOSS project. That requires a lot of resources beyond the event itself.

    2 points
  • Posted to What’s your favourite/dream colour picker?, Dec 22, 2018

    I agree with everything Kemie said (although I don't care too much about the exportability of palettes, but hey, nice to have!).

    Added to that, please consider the hue/saturation/brightness model that is, at least in my experience, used most by designers is … not great. I don't think that when it was developed in the 1970s, its creators thought it would still be in use, this much, in professional design software. Sure it's easier to use than RGB and CMYK (or LAB, I never really got a grip on LAB colors). But it's quite useless when trying to find colors with matching saturation and brightness. One would think that two colors with the same brightness value would be equally bright, but perceived brightness depends on hue. That's just one issue of many (here's some more info on that). A color model (or a mode on top of HSB) that takes perception into account would be soooo nice.

    0 points
  • Posted to Tired of my Apple Magic Keyboard. What should i buy?, Dec 21, 2018

    Buying stuff you don’t need won’t make you happy. If you want to spend the money anyway, consider giving it away—that will give you probably more satisfaction, studies show. Check https://www.effectivealtruism.org/ if you’re worried about where it would be best spent.

    0 points
Load more comments