Flexbox Case Studies – Tutorials to help you achieve common Flexbox layouts.
Set Your Text in Motion with These Dazzling Effects – Snippets that prove text doesn’t have be stationary.
Terminal CSS – Attention terminal lovers, there’s now a CSS framework for you.
Complete Guide to Using WebP Image Format – WebP images can have a significantly smaller file size than other formats.
Node.js Best Practices – A listing (updated weekly) of top-ranked Node.js related articles.
Design Checklist for the Perfect Charts – Important considerations when implementing charts into your project.
Sleek Dashboard – A free Bootstrap 4 admin template and UI kit.
Table Design Patterns On The Web – Best practices for using tables on the modern web.
Subtle interactions demand subtle awareness – Three under-the-radar concepts for better UX.
How to Test Your WordPress Website for PHP 7.x Compatibility – Ensure that your site is ready to work with recent versions of PHP.
Morpherings – CSS buttons that morph into forms.
Freelancing: The Risks and Fears of Going it Alone – Tips for navigating the scary side of running a freelance business.
UX Design Case Studies – The best case studies of 2018.
x-spreadsheet – A JavaScript (canvas) powered spreadsheet for the web.
Matter – A collection of Material Design components in pure CSS.
Immutable Styles – A library for styling web interfaces with a focus on predictability and robustness.
Palette App – A tool for building, analyzing and editing smooth color palettes.
Webfont – Create and manage your own custom font icons.
Polarite – Generate color schemes with the help of A.I.
Follow Speckyboy on Twitter or Facebook for a daily does of web design resources and freebies.
The post Weekly News for Designers № 473 appeared first on Speckyboy Web Design Magazine.
This was a talk from the first day, but it required some more processing before writing about it. Cyrille is one of my favorite speakers. He's fast, funny and brings a lot of interesting topics to the table. So many that it's sometimes hard to keep following his train of thought, and writing down some notes at the same time.
A central concept from his talk was what he called the waterline between IT and the business. In a traditional scenario, developers get provided with "work" on a case-by-case basis. They don't learn about the general idea or plan, or even the vision, goal or need that's behind the "work item". They just have to "implement" it. It leads to badly designed code. But it also leads to the wrong solutions being delivered. If only developers could have talked with the people who actually have the problem for which they build the solution. Maybe there's another problem behind it, or maybe the business has provided the developer with a solution, instead of a problem. To higher the waterline means to get more involved with the customers and users, to understand their problems, and work together on a solution. Make sure you get involved.
When looking for the right solutions, investige the problems and use the following heuristic: "Consider the intensional alternative". Cyrille considers "intensional" a pedantic word and likes it. It's opposed to "extensional". Extensional corresponds to enumarating the results. Intensional means defining the predicate which will produce those results. Looking for intensional solutions means you'll end up with a better understanding of the problem. And also an automatable one.
While collecting these intensional aspects of existing business problems, as a developer you will be building a theory about that business. Cyrille warns against the illusion that a domain is simply a lot of information withs if-s on top. Business is messy, so we shoudn't be obsessed with rules. Some parts of a domain allow theorizing, some don't.
This nicely aligns with my own experience, trying to understand a business domain. Domain experts often aren't aware of the inconsistencies, or impossible rules they come up with. Once you bring in some logic, some rules seem reasonable but just aren't feasible. These may be areas where there's manual intervention in an otherwise automated system.
Another interesting concept Cyrille brought up was that of "skeuomorphism". He noticed that software solutions seem to continue building on technology from the past. Software systems often look like they're rebuilding a paper bureaucracy, but now it's digital. You can't really be "disruptive" if you don't think about radically different ways of solving some problem for the user. This was a bit of shock, because I realized that I often use "paper metaphors" to find out a possible solution for a design issue. Then again, maybe there's room for both - a paper metaphor as a design tool, yet a non-paper bureaucracy inspired software solution.
Identifying herself as a "feedback fairy", Maaret talks about testing, in a very broad sense. It doesn't only cover automated testing, but also exploratory testing, and what you're doing with them. Tests don't break code, they break the illusions you have about it. The way Maaret explained testing, I immediately became scared of all the illusions I have about my code and that I should start breaking them.
I like how Maaret used the term "heuristics", like more DDD-ers do, to share with us how she and other testers do their work. It seems it's very common to share heuristics in the testing community. Very interesting! I don't think programmers share them as freely as they should.
Testing an application starts with realizing: you don't know much. So you have to create some sort of a map of what's there (functions, data, the platform, etc.). Start to discover, and never be bored. Always look for the interesting things, and "poke it until it pops".
In general, what you'll find is all kinds of illusions (they could be called "assumptions", I think). In testing an application ("it has high code coverage, so it's tested") but also in the general activity of developing software ("if we have this new feature, we'll earn more money").
Thinking in terms of illusions, I think most development teams are very good at them. We have all kinds of ideas about our code, our way of working, the application, our teammates, the company, etc. But they aren't really tested. It'll be smart to challenge them.
Also, looking at how others approach their problems is very useful. There will be a different perspective that you
Truncated by Planet PHP, read more at the original (another 826 bytes)