This is just a quick post sharing something I was able to figure out after doing some research.
The situation: our application throws exceptions by means of "talking back to the user".
As developer we don't want to be notified about all these exceptions.
They aren't as important as any other exception that should be considered "critical".
Still, we do want to find these exceptions in the logs, because they can sometimes provide valuable feedback about the usability of the system.
So basically we just want Symfony to log the exception, but dial the standard log level "critical" for certain types of exceptions down to "info".
Monolog has the concept of a processor for that (represented by the optional ProcessorInterface).
The implemented process() method should return the modified log record, which is actually an array containing the different parts of a log record (the level, the message, and the context).
Since not every log record is related to an exception, we don't have to do anything in most cases.
Here's the code:
use Monolog\Logger;
use Monolog\Processor\ProcessorInterface;
use Symfony\Component\HttpKernel\EventListener\ErrorListener;
use Symfony\Component\HttpKernel\Exception\HttpExceptionInterface;
use Throwable;
final class AdjustLogLevelForExceptions implements ProcessorInterface
{
public function __invoke(array $record): array
{
if (!isset($record['context']['exception'])) {
/**
* Symfony's ErrorListener will provide a Throwable through the log message's context.
* If the context has no "exception" key, we don't have to further process this log record.
*
* @see ErrorListener::logException()
*/
return $record;
}
$throwable = $record['context']['exception'];
if (!$throwable instanceof Throwable) {
// For some reason the provided value is not an actual exception, so we can't do anything with it
return $record;
}
// Change the log level if necessary
$modifiedLogLevel = $this->determineLogLevel($throwable, $record['level']);
$record['level'] = $modifiedLogLevel;
$record['level_name'] = Logger::getLevelName($modifiedLogLevel);
return $record;
}
private function determineLogLevel(Throwable $throwable, int $currentLevel): int
{
if ($throwable instanceof UserErrorMessage) {
// These are exceptions that will be rendered to the user.
return Logger::INFO;
}
return $currentLevel;
}
}
Now you only have to register this processor as a service and tag it as monolog.processor:
services:
AdjustLogLevelForExceptions:
tags:
- { name: monolog.processor }
If you use auto-wiring and have set up auto-configuration for the directory where the AdjustLogLevelForExceptions is located you don't even have to tag this service.
The MonologBundle should automatically do that for you.
Okay. I’m going to come out and say it. Designers are often way too territorial about their designs. It’s only natural, of course. You spend years and years developing your design skills, you create the ideal process for your ideal user to follow so that (you’re certain) they will get the best experience possible.
But here’s the thing: users may not stick to your original vision of how your design “should” be used. The truth is, they don’t have to, and, if your views on their user experience are off the mark, they shouldn’t.
We look at some ways in which users often give designers a run for their money when it comes to the ideal user experience, and explore whether a designer’s opinion means more than the user’s.
Technicality Versus Practicality
Sometimes, there is a clear battle between the designer’s creative vision and what the user really wants. This can be seen in major corporate projects as well as individual website designs for a single client.
Designers, by virtue of being creative professionals, often let their ego get in the way of creating a truly functional product. Some of this is justified. After all, you want to maintain your reputation for quality, both functionally and visually.
But, as the saying goes, form follows function. You don’t want to get so caught up in maintaining your design’s visual appeal that you lose sight of what’s best for the user.
The best way to avoid this pitfall is to regularly interact with your target audience. Talk to people who interact with your website, app, or other designs. Ask them questions about their experience – what they feel could be improved, how your design is helping them achieve solutions to their problems, et cetera.
This knowledge will be invaluable not just to your users and your clients, but also for expanding your career as a designer who really “gets” the ideal user experience.
Co-Opting Your Environment
Users, by definition, use things. Sounds obvious, I know, but many designers forget this simple fact, or think it only applies to a narrow set of rules. But people who use things are amazingly adaptable. They use the world around them to create their own design solutions, if the ones provided aren’t satisfactory. All users have this ability – including you.
Yes, you routinely violate many designers’ perfect visions for how you should be using their products. Ever scribbled a phone number or email address on the back of someone’s business card? You rebellious user, you.
From holding a supposedly “ergonomic” pen or tool in a way that’s unconventional, but more comfortable for you, to breaking out the sugru and physically altering a product to fit your individual needs, we all take advantage of what I call the user’s authority.
Following Leaders And Precedents
Once a design leaves your studio, it officially belongs to the user, and they will adapt it however they see fit. People use design to communicate with one another out in the world, often in ways that the designer never intended or even expected. Your design may end up serving a completely different purpose than what it was originally created for.
Think about the last time you gave directions to a tourist or someone in your town who was lost. You probably told them something closer to “head left at the intersection with the weird billboard,” rather than rattled off a dry list of street names.
Design infiltrates our daily lives, and we use it as placeholders, markers, and guides every day.
Does The Design Slow Down Progress?
The most important thing to consider in any design is whether the user can solve the problem they have with the maximum amount of efficiency. If your design is impeding them from doing this, then it’s a failure as a design.
Again, talking to your target users will yield a wealth of information that can help you avoid this common crisis. I’m not talking about formal “focus group” style research either. Even something as simple as a 5 question email survey can help tremendously in the design process.
For example, if you don’t know that the majority of your users are skipping the calls to action that you’ve added to your website, pretty much the only way you can find this out is by interacting with them.
It’s unlikely that they’re going to tell you on their own, and, quite honestly, it’s not their responsibility to do so. You’re the designer – it’s your job to make sure that your designs are providing maximum efficiency for your users.
Building Up Trust
Well designed websites instill a sense of trust in the user. When you see a crappy looking website, your first instinct is that it’s probably a bit shady, or even an outright scam.
Why? Well, because a legitimate business will usually at least make an attempt to have a professional-looking front.
The post Does A Designer’s Opinion Mean More Than The User’s? appeared first on Speckyboy Design Magazine.
