How to create a persuasive portfolio is a very popular topic in our UX Mastery community, so I have no doubt that our next Ask Me Anything session is going to be a busy one.
Perhaps the most frequently asked question is how to find projects or case studies to build a portfolio if you don’t have a job. If that’s you – you’re in luck.
We’re pleased to announce that career coach Louise Campbell will be next up in our Slack channel, and these are the kinds of questions that she is going to be answering.
If you need advice on finding appropriate projects, documenting case studies, or building a more persuasive portfolio, don’t miss this free session.
Louise Campbell is a Lead UX Design consultant for giant eCommerce companies. She started out at 19 as a junior print designer for Littlewoods Home Shopping Group. Over the last 15 years has worked her way up to consulting for luxury e-commerce companies including Net-a-porter.com, MrPorter.com, The Body Shop, Benna.co.uk, and travel giant Greyhound.com.
Louise is also a career transition coach for ambitious graphic designers who want to make it big in UXD. She teaches a free weekly mini-class to show you ‘How to Create a Persuasive Portfolio’ at UpSkillMastery.com.
If you can’t make the live session but have questions, we’d love to collect them ahead of time and we’ll ask Louise on your behalf. You can submit your questions here. We’ll publish the responses (along with the full transcript) in the days following the session.
These sessions run for approximately an hour and best of all, they don’t cost a cent. We run them in our dedicated public Slack channel. That means that there is no audio or video, but a full transcript will be posted up on here in the days following the session. If you’re not familiar with Slack, you’ll need to request an invite to our channel the first time only – from then on you’re part of the family and you’ll have automatic access to new sessions.
The post “I teach UXers how to create a persuasive portfolio : Ask me Anything?” appeared first on UX Mastery.
Lea Verou is back to her old tricks in finding creative ways to utilise the power of CSS. In this short post she explains a neat trick using CSS variables. (lea.verou.me)
When working in a team, Matt Zabriskie reminds us that it is important to market your individual contribution, as it is unlikely anyone else will. Communication appears to be the key to making sure your efforts are recognised. (mattzabriskie.com)
Whatever your needs or preferences, there’s almost certainly a way to access the web, theoretically. But, in reality, the web is as a mess, and is a human right issue in respect of disabled people accessing it. This post explores how we got into this mess and ways we can fix it. (uxdesign.cc)
Harry Roberts shares an approach to refactoring CSS (or any language), which has been called The Three I’s: Identify, Isolate, Implement. (csswizardry.com)
Matt Cooper-Wright shares with us how automation helped his design team dig into their data and add magic to their prototypes. (medium.com)
After attending a workshop, Sarah Drasner found herself particularly interested in a practical piece of ES6 that she previously had not noticed: Destructured Objects as Parameters. She shares her newfound interest with us. (css-tricks.com)
Webpack is gaining traction everyday and with Webpack 2 just around the corner now is a better time than ever to take the time learn why it is such a great tool. (github.com)
The second episode from Front End Center that looks into the currentColor keyword. The talk covers the core CSS concepts that underpin it, what currentColor the keyword actually means and then looks in-depth at a demo using a bunch of related CSS techniques. Make time for this. (youtube.com)
Here is one to help you create a customised JSON file to generate product related content. (medium.com)
A hassle-free way to self-host Google fonts. (google-webfonts-helper.herokuapp.com)
We are a diverse team from around the world working together on a mission to make DuckDuckGo the world’s most trusted search engine and we want your help! Join us as a Senior Product Designer and become part of the team leading the transformation of the DuckDuckGo user experience. (duckduckgo.com)
X-Team is an international company founded in Melbourne, Australia that helps companies scale their development teams by providing them with extraordinary developers from around the world. If you are keen on a 100% remote gig with a large about of variety we want to hear from you. (x-team.com)
The post Web Design Weekly #251 appeared first on Web Design Weekly.
In a recent thread on SitePoint's forums, some code was given to let one dropdown box control when another dropdown box is visible. Even though the code worked just fine, I realized that it left much to be desired. It was brittle and incapable of withstanding even small changes to the accompanying HTML.
Here is the original CSS code:
#second { display: none; }
#second.show { display: block; }
and the original JavaScript code:
document.getElementById("location").onchange = function () {
if (this[this.selectedIndex].value === "loc5") {
document.getElementById("second").className = "show";
} else {
document.getElementById("second").className = "";
}
};
In this article, I'll demonstrate some simple techniques that can be applied to the above code in order to make it easier to reuse and more accommodating to future change.
JavaScript has many ways to achieve the same task, and some of them work better than others. Are there ways to improve the code right now so that we don't have to come back to it later on? Sure! But when there are several possible methods of doing something, how can we determine which one is likely to work best?
One common technique for improving code is to remove duplication (using the don't repeat yourself principle). From there though, it can be more useful to go from specific to more generic code which allows us to handle a wider range of situations.
Specific code tends to be brittle when it comes to handling future changes. Code doesn't exist in a vacuum, and will need to change in response to other actions around it and in the HTML code. With the benefit of past experience though, we can look at common changes that occur and improvements that reduce number of times we need to revisit the code. Invariably you will find that this means making the code more generic.
But beware! It can be easy to make our code too generic to the point that it becomes difficult to understand. Striking a good balance between generic and readable is where we find improved code.
During the course of test driven development (TDD) you can't help but to come across this principle as a part of the process:
As the tests get more specific, the code gets more generic.
The Cycles of TDD by Robert C. Martin covers this idea well. The main benefit here is that generic code ends up being able to handle a wider range of situations and scenarios.
Looking at the above code, some obvious specific to generic improvements are immediately available.
onchange event handler is problematic in so far as it can be overwritten. We should consider using addEventListener instead.className property will overwrite existing class names. We should consider using classList instead.After making all of these improvements, we'll end up with code that is more resilient to future changes, and is easier to update. So let's get started ...
The ID of the dropdown box ("location") and its trigger value ("loc5") are useful references to keep together. The second <select> element is also being referred to twice, which we can pull out to a separate variable to prevent clutter and provide easier maintenence.
For example, instead of having two references to the same element that would need to be changed if the element's ID changed:
// bad code
if (...) {
document.getElementById("second").className = "show";
} else {
document.getElementById("second").className = "";
}
We can store a reference to this element in a variable, limiting future change to only the place where the variable is assigned:
// good code
var target = document.getElementById("second");
if (...) {
target.className = "show";
} else {
target.className = "";
}
By pulling these strings out together to the top of the code, and separating out the parts of the if condition, the specific to generic technique results in code that is easier to maintain, both now and in the future. If any of the identifiers or option values are changed, they can all be easily found in the one place, instead of hunting through the code for all of their occurences.
// improved code
var source = document.getElementById("location");
var target = document.getElementById("second");
var triggerValue = "loc5";
source.onchange = function () {
var selectedValue = this[this.selectedIndex].value;
if (selectedValue === triggerValue) {
target.className = "show";
} else {
target.className = "";
}
};
Continue reading %JavaScript Refactoring Techniques: Specific to Generic Code%