by via Awwwards - Sites of the day
Friday, March 31, 2017
P22 Studio
by via Awwwards - Sites of the day
Google Analytics: How to Analyze the Behavior of Your Site Visitors
Do you want to learn more about how people use your website? Wondering how the Behavior reports in Google Analytics can help? To explore how to navigate the Behavior section of Google Analytics, I interview Andy Crestodina. More About This Show The Social Media Marketing podcast is an on-demand talk radio show from Social Media [...]
This post Google Analytics: How to Analyze the Behavior of Your Site Visitors first appeared on .
- Your Guide to the Social Media Jungle
by Michael Stelzner via
Five Qualities of a Mature Design Culture
Throughout your career as a designer, you’ll work for many organisations, each with varying levels of design maturity. It’s important to enjoy the time spent at each of them, and pick up great experiences along the way.
For many designers, culture is a driving factor in choosing a company to work for and build a career. Design culture is more than ping pong tables, free food and a pretty workspace. It’s about providing the tools and an environment to perform at your best.
When evaluating the maturity level of the design culture of an organisation, some questions you might like to ask are:
- Is design positioned within the company as you would expect it to be?
- Are decisions being made without design having a seat at the table?
- Do most of the projects get buy-in from the organisation when they are started by non-design functions?
- Is design being brought in as a last-minute box to check before a product is launched?
- Is the UX team the only advocate for the user, while the rest of the organisation believes that they can just release a product and everyone will buy it?
- Are outside vendors and agencies championed as experts more than the internal team, who are just as capable?
- Are designers scattered throughout the teams, hidden in a dark corner somewhere feasting on scraps whenever the business decides to throw them a bone?
No matter the level of design maturity, each organisation has unique cultural strengths and areas that can be improved. While cultures and their individual fit may vary, these are five qualities to identify a mature design culture.
-
Design is represented at the executive level
Whether you have a Chief Design Officer, or a design level VP, you need to have executive support for design at the highest possible level. This role shows an organisational commitment to design both financially and philosophically. There is no longer a need for the justification of design, it is positioned as a function that’s integral to innovation and future success.
-
A common vocabulary
A mature design culture recognises that design is not the centre of the corporate universe. Having a shared vision and vocabulary among stakeholders with competing priorities and different backgrounds means there is no longer a need to translate design language or business acronyms.
The business manager is worried about profits, the marketing manager about brand, so leave the design lingo behind to clearly communicate solutions in terms universally understood. A common vocabulary allows everyone to be on the same page, speaking the same language.
-
Meaningful projects
One of the main things designers look for in an organisation is the quality of projects they’ll be working on. It doesn’t matter how fun or exciting a project is, if it never sees the light of day it’s considered throw away work.
The last thing the world needs is another weather app…
Everyone wants to work on projects that make a difference. The last thing the world needs is another weather app – there are plenty of good ones already. Mature design cultures aren’t afraid to kill a project from time to time and refocus the learning and efforts into another solution.
-
Design efficiency
Reinventing the wheel is not efficient. It’s also not fun for designers or developers to continually recreate the same elements for every project. Organisations should have efficiencies in place for design activities and collaboration.
Depending on maturity level, these can range from individual elements like such as research method cards, a style guide or a workshop playbook to a full-blown design system comprised of a design language or pattern library with working components. The design activities and processes shouldn’t compete with business processes. Instead, they should be fully integrated into one single process.
-
Talented people
The best teams are comprised of individuals who continually learn from one other.
Companies with a more mature culture have less turnover. While culture may attract talent, it’s the talent that keeps the culture evolving. The ideal team would be high-performing, comprised of individuals who continually learn from one other. It’s the best team you’ve ever worked for, one that shares accountability and pushes the other members to grow and succeed.
Culture can’t be forced. It has to come together organically through the continuous evolution of a team as a result of growing in size and experience. The way to cultivate culture is to influence others by putting in the work, building relationships, fostering collaboration, having uncomfortable conversations, making tough decisions, being accountable and influencing others by learning from mistakes and leading by example.
What culture do you look for in a workplace? Let us know in the comments or the forums.
During March, we’ve looked at how to better engage with stakeholders. Catch up on our latest posts:
- Using A/B Testing to Drive Constructive Conflict with Stakeholders
- Proven Strategies to Win Over Stakeholders for Your UX Project
- What’s the Impact of Investing in UX?
- Ego and Evidence Drive Designs, but Which One is Right?
- Doing Strategy to People
The post Five Qualities of a Mature Design Culture appeared first on UX Mastery.
by Andy Vitale via UX Mastery
Taking Steps towards Scrum
The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
For most of this book, we've been talking about the practicalities of scrum. Although the core definition of scrum is very versatile—supporting a wide range of applications—we've gone into a fairly opinionated and detailed explanation of the mechanics of scrum as it can be applied in web and mobile teams. (Many of these principles and practices, however, apply just as well to other kinds of development work.)
Now that we have some shared vocabulary and concepts, in this chapter we're going to discuss how to get a team started with scrum. We'll go into more detail about the arguments for scrum when doing web and mobile development. We'll discuss what scrum is best for, how it compares to the alternatives, and provide answers to some of the questions that come up when making the case for scrum and applying it in a company.
Continue reading %Taking Steps towards Scrum%
by M. David Green via SitePoint
Thursday, March 30, 2017
Writing Better JavaScript with Flow
How often have you found yourself tracking down a bug in some code, only to find the error was something simple that should have been avoidable? Maybe you passed the arguments to a function in the wrong order, or perhaps you tried to pass a string instead of a number? JavaScript's weak typing system and willingness to try to coerce variables into different types can be a source of a whole class of bugs that just don't exist in statically typed languages.
March 30th, 2017: The article was updated to reflect changes to the Flow library.
Flow is a static type checker for JavaScript first introduced by Facebook at the Scale Conference in 2014. It was conceived with a goal of finding type errors in JavaScript code, often without having to modify our actual code, hence consuming little effort from the programmer. At the same time, it also adds additional syntax to JavaScript that provides more control to the developers.
In this article, I'll introduce you to Flow and it's main features. We'll look at how to set it up, how to add type annotations to your code, and how to automatically strip out those annotations when running the code.
Installation
Flow currently works on Mac OS X, Linux (64-bit) and Windows (64-bit). The easiest way to install it is via npm:
npm install --save-dev flow-bin
and add it to your project's package.json file, under the scripts section:
"scripts": {
"flow": "flow"
}
Once this is done, we’re ready to go ahead and explore its features.
Getting Started
A configuration file named .flowconfig must be present at the root of the project folder. We can create an empty config file by running the command:
npm run flow init
Once the config file is present, you can run ad-hoc checks on the code within your project folder and any subfolders by running the following command at the terminal:
npm run flow check
However, this is not the most efficient way to use Flow since it causes Flow itself to recheck the entire project's file structure every time. We can use the Flow server, instead.
The Flow server checks the file incrementally which means that it only checks the part that has changed. The server can be started by running on the terminal the command npm run flow.
The first time you run this command, the server will start and show the initial test results. This allows for a much faster and incremental workflow. Every time you want to know the test results, run flow on the terminal. After you're done with your coding session, you can stop the server using npm run flow stop.
Flow's type checking is opt-in. This means that you don't need to check all your code at once. You can select the files you want to check and Flow will do the job for you. This selection is done by adding @flow as a comment at the top of any JavaScript files you want to be checked by Flow:
/*@flow*/
This helps a lot when you're trying to integrate Flow into an existing project as you can choose the files that you want to check one by one and resolve any errors.
Type Inference
Generally, type checking can be done in two ways:
- Via annotations: We specify the types we expect as part of the code, and the type checker evaluates the code based on those expectations
- Via code inference: The tool is smart enough to infer the expected types by looking at the context in which variables are used and checks the code based on that
With annotations, we have to write some extra code which is only useful during development and is stripped off from the final JavaScript build that will be loaded by the browser. This requires a bit of extra work upfront to make the code checkable by adding those extra type annotations.
In the second case, the code is already ready for being tested without any modification, hence minimizing the programmer's effort. It doesn't force you to change how you code as it automatically deduces the data type of the expressions. This is known as type inference and is one of the most important features of Flow.
To illustrate this feature, we can take the below code as an example:
/*@flow*/
function foo(x) {
return x.split(' ');
}
foo(34);
This code will give an error on the terminal when you run the npm run flow command, as the function foo() expects a string while we have passed a number as an argument.
The error will look something like this:
index.js:4
4: return x.split(' ');
^^^^^ property `split`. Property not found in
4: return x.split(' ');
^ Number
It clearly states the location and the cause of the error. As soon as we change the argument from a number to any string, as shown in the following snippet, the error will disappear.
/*@flow*/
function foo(x) {
return x.split(' ');
};
foo('Hello World!');
As I said, the above code won't give any errors. What we can see here is that Flow understands that the split() method is only applicable to a string, so it expects x to be a string.
Nullable Types
Flow treats null in a different way compared to other type systems. It doesn't ignore null, thus it prevents errors that may crash the application where null is passed instead of some other valid types.
Consider the following code:
/*@flow*/
function stringLength (str) {
return str.length;
}
var length = stringLength(null);
In the above case, Flow will throw an error. To fix this, we'll have to handle null separately as shown below:
Continue reading %Writing Better JavaScript with Flow%
by Nilson Jacques via SitePoint
This week's JavaScript news, issue 328
|
by via JavaScript Weekly
Subscribe to:
Posts (Atom)