[ This is a content summary only. Visit our website http://ift.tt/1b4YgHQ for full links, other content, and more! ]
by Web Desk via Digital Information World
"Mr Branding" is a blog based on RSS for everything related to website branding and website design, it collects its posts from many sites in order to facilitate the updating to the latest technology.
To suggest any source, please contact me: Taha.baba@consultant.com
This article originally appeared on the OKTA blog. Thank you for supporting the partners who make SitePoint possible.
React has quickly become one of the most favored front-end web frameworks, and is second only to plain old HTML5, according to JAXenter. So it’s no surprise that developers are learning it, and employers are asking for it.
In this tutorial, you’ll start with a very simple React app with a couple of pages and some routing built in, and add authentication using Okta’s Sign-In Widget. The Sign-In Widget is an embeddable Javascript widget that allows developers to use Okta’s secure, scalable architecture with a minimum of effort from within React applications. Let’s get started!
Start by cloning the simple React seed project.
git clone http://ift.tt/2zSvQoE okta-react-widget-sample
cd okta-react-widget-sample
Install the Okta Sign-In Widget using npm.
npm install @okta/okta-signin-widget@2.3.0 --save
This will add the Okta Sign-In Widget code to your node_modules folder. We’ll be using version 2.3.0 of the Sign-In Widget.
Then add the styles for the widget in your index.html file from the Okta CDN. Add these lines inside the <head> tag:
<link
href="http://ift.tt/2hoRudq"
type="text/css"
rel="stylesheet"/>
<!-- Theme file: Customize or replace this file if you want to override our default styles -->
<link
href="http://ift.tt/2zSvQVG"
type="text/css"
rel="stylesheet"/>
First, create a folder called auth in the ./src/components folder, then create a file called LoginPage.js where the LoginPage component will go.
Start with the most basic of components:
import React from 'react';
export default class LoginPage extends React.Component{
render(){
return(
<div>Login Page</div>
);
}
}
This little component doesn't do much but at least you now have a handle to add the LoginPage to your routing. So in your ./src/app.js file, you'll import the component at the top:
import LoginPage from './components/auth/LoginPage';
and then add the route inside the main route (the one with the path of "/")
<Route path="/login" component={LoginPage}/>
In order to use Okta as your OpenID Connect provider for authentication, you’ll need to set up an application in the Okta developer console.
If you don't have an Okta developer account, go create one! Once you're logged in, click on Applications in the top navbar, then click Add Application. Select SPA as the platform and click Next. Change the redirect URI to http://localhost:3000, and click Done. The application will be created with the following settings:
Now that you have an application created in Okta, you can set up the widget to talk to your new app!
import React from 'react';
import OktaSignIn from '@okta/okta-signin-widget';
export default class LoginPage extends React.Component{
constructor(){
super();
this.widget = new OktaSignIn({
baseUrl: 'https://{oktaOrgUrl}',
clientId: '{clientId}',
redirectUri: 'http://localhost:3000',
authParams: {
responseType: 'id_token'
}
});
}
render(){
return(
<div>Login Page</div>
);
}
}
Copy the Client ID generated from your application's settings page and paste it over {clientId}. Make sure you also replace {oktaOrgUrl} with your Okta organization URL, which you can find by going back to the main Dashboard page in the developer console. Usually it will look like: http://ift.tt/2zS87VJ.
Thus far you've imported the OktaSignIn function from the Okta Sign-In Widget npm module you installed earlier. Next, in the constructor of the component, you initialized an instance of OktaSignIn with the configuration for the application. This way, the application code will be able to talk to Okta and Okta will recognize that this is the app you just created.
Next, you’ll create the code to actually render the Sign-In Widget to the page! You'll need to change your render method to create an HTML element you can render the widget into. Make sure to get a reference to the element that will be rendered. Then, add a componentDidMount function to make sure you don't try to render the widget before the HTML element is on the page.
Continue reading %Build a React App with User Authentication in 15 Minutes%
A few times a year something really blows my mind in the web development space and this is one of them. High fives to the Airbnb team for pushing things forward. (airbnb.design)
If you happen to work on a product that is getting big and bigger by the day and performance is becoming an issue, read this. Oh and send it to your manager. (infrequently.org)
Another entertaining post by David Gilbertson that will no doubt enlighten your z-index skills to the next level. Great read even if you are a z-index guru. (hackernoon.com)
Still finding your feet with React? Canberk Morelli passes on 6 tips that you should find helpful. (engineering.opsgenie.com)
In this article, Tom Graham and André Gonçalves discuss some of the most common visual impairments, focusing on color-blindness to explain how you can make small changes to your workflow and products to ensure you’re not alienating users. (smashingmagazine.com)
You don’t need to do too much to receive the juicy benefits of HTTP/2. If you can steer away from some comfortable old patterns and into the sunny new world you’re in for some speedy times as Kellen Person explains. (fly.io)
The Graphcool Framework is a comprehensive collection of building blocks covering the entire spectrum of developing modern, data-centric GraphQL. (graph.cool)
Your files deserve a safe home. Organizing, sharing & approval of creative in a customizable portal; everything is easier with Bynder Orbit. (bynder.com)
Chris Chan shares some really great advice on ways you can go above and beyond as a product designer. (medium.com)
If you have ever been a little bamboozled about what should or shouldn’t be in the head of your document this in-depth list is for you. (github.com)
As a Product Designer, you will be responsible for working closely with a cross-functional team to build new features and a/b tests that will help our 3.5M+ members engage with Creative Market and drive meaningful revenue for the 20k+ creators on our platform. (creativemarket.com)
We are a small, collaborative team of multidisciplinary designers, and are looking for experienced product designers to help us dive deeper into our product vision, and to strengthen our brand across all the places we interact with our customers. (mixpanel.com)
The post Web Design Weekly #297 appeared first on Web Design Weekly.
A tutorial about creating simple push menu with pure Javascript and CSS.
The following is a short extract from our book, Designing UX: Forms, written by Jessica Enders. It's the ultimate guide to form design, a key part of effective UX design. SitePoint Premium members get access with their membership, or you can buy a copy in stores worldwide.
We can subtly communicate with the user through a few tweaks of spacing.
Human beings see things that are close to each other as being related. Conversely, things that are not related usually have some space between them.
These principles tell us to put the parts of a question—label, question-level help and answer fields—close together. Our form is pretty good for this so far, but let’s just move the labels a bit to the right, so they’re closer to their fields:
Flush right labels should be close to their fields.
On the other hand, there needs to be some distance between each question:
Questions should be far enough apart that it’s clear where one ends and the next one starts.
Remember how the focus of a user’s vision is about nine characters wide? Well, this means question-level help that’s on the right side of a field often won’t be seen:
Their focus on fields means many users won’t even see the question-level help in this form.
We could move the question-level help underneath the field, but that means users might not see it until after they’ve answered. It’s also less accessible.
Question-level help below the field is not especially usable or accessible.
The best place for question-level help is between the label and the field (as shown in the image below). Formatting instructions—like the DD MM YYYY on date of birth—should go above the field:

Formatting instructions positioned above the field
Other question-level help should go below the label. See the ABN, employee and marketing questions for examples of this:
Other question-level help positioned below the label.
Finally, when we use checkboxes and radio buttons, we need to make sure the labels are close to the right button or box. If they’re too far away, things get confusing, particularly if you aren’t shading the touch area:
The distance between the labels “Yes” and “No” and their respective radio buttons means the user has to stop and think.
Here’s an even more extreme illustration of poorly spaced labels on radio buttons:
It’s likely that many users will give an unintended rating, given the poor spacing here.
While we’re adjusting spacing, let’s fix up our text box widths.
At the moment, aside from the text boxes for date of birth, all our text boxes are the same width:
However, the width of a text box tells the user what sort of information is needed. The user experience will be better if we make the sizes proportional to the expected information (as we have, in fact, already done with date of birth):
Note we’re talking about visual width here, not acceptable number of characters. The email address field may have a visual width as shown, but should still accept up to 256 characters.
Another important aspect of text box spacing is the space they have inside. This empty space is how users know they need to type something in there.
Way too many forms have text boxes that aren’t empty. The two main culprits are:
Do not give your fields a background color. Background color in fields makes them look like buttons (just as buttons without background color look like fields):
On this form, background color makes fields look like buttons, and vice versa.
A simple border on four sides is enough to show users where to type:
You don’t need much to show users where their answers go.
Just make sure your border can be seen:
The field borders on this form are so light they’re nearly impossible to see.
Continue reading %Designing Form Layout: Spacing%
The following is a short extract from our book, Designing UX: Forms, written by Jessica Enders. It's the ultimate guide to form design, a key part of effective UX design. SitePoint Premium members get access with their membership, or you can buy a copy in stores worldwide.
You and a friend are each driving to a restaurant for dinner. Both of your routes go down a highway with two lanes. The highways are the same length. On your route, all the slow cars are doing the right thing and sticking to one lane, so you can whizz past in the other. On your friend’s route, the slow cars are scattered across both lanes of the highway, so she has to weave in and out. Which one of you will get to the restaurant first?
A straight, unobstructed route is fastest for driving, and also for form filling. So your next step is to vertically line up all your form fields, as well as the main button on the page (called the primary action button):
Now you’ve created a straight, unobstructed, vertical path to completion. Not only have you made it faster for your form to be filled out, it looks neater and simpler too. (We’ll talk about the distance between some fields and their labels shortly.)
Because a vertical path to completion makes a form longer, you may be tempted to squeeze some questions next to each other:
In this form, the Security Code and Postal Code questions have been put beside other questions
This is a bad idea, for the following reasons:
Also, as you may recall from Chapter 3, for users it’s the perceived length of the form, not the actual length, that matters. The vertical path to completion makes form filling not only objectively faster, but it makes it feel fast.
One way you can sometimes save space, however, is with answer fields. Look at the answer fields for the marketing consent question:
Whenever the answer fields are small, we can put them horizontally. (For this purpose we define “small” as three or fewer options, all with short labels.) The form will still work for touch, and on small screens. Marketing consent is just such a question:
In fact, date of birth is also a question with small answer fields. You may not have realized we’ve already put them on one line:
But remember: you can only put answer fields beside each other if they’re small. Otherwise, the design won’t work in some cases. Social networking, for instance, has quite a large number of answer options. If we try to put them horizontally, they’ll go off the edge—especially on mobile—and invoke the dreaded horizontal scrollbar:
If we position a long set of answer fields horizontally, we’re likely to conjure the horizontal scrollbar, even on larger screens
If our answer fields aren’t small, it’s even more likely we’ll cause the horizontal scrollbar to appear on mobile.
Assuming we can’t build a custom widget, it’s better to leave these as a single vertical list:
Larger sets of radio buttons or checkboxes should be vertically aligned.
Vertical alignment of sets of radio buttons or checkboxes works on mobile too.
There’s a problem with the mobile view of our form, which you may have noticed from some of the illustrations above. On a small screen, when the focus is in a text box, the corresponding label isn’t visible, just like this example:
Continue reading %Designing Form Layout: Alignment%
MySQL is still the world's most popular relational database, and yet, it's still the most unoptimized - many people leave it at default values, not bothering to investigate further. In this article, we'll look at some MySQL optimization tips we've covered previously, and combine them with novelties that came out since.
The first - and most skipped! - performance upgrade every user of MySQL should do is tweak the configuration. 5.7 (the current version) has much better defaults than its predecessors, but it's still easy to make improvements on top of those.
We'll assume you're using a Linux-based host or a good Vagrant box like our Homestead Improved so your configuration file will be in /etc/mysql/my.cnf. It's possible that your installation will actually load a secondary configuration file into that configuration file, so look into that - if the my.cnf file doesn't have much content, the file /etc/mysql/mysql.conf.d/mysqld.cnf might.
You'll need to be comfortable with using the command line. Even if you haven't been exposed to it yet, now is as good a time as any.
If you're editing locally on a Vagrant box, you can copy the file out into the main filesystem by copying it into the shared folder with cp /etc/mysql/my.cnf /home/vagrant/Code and editing it with a regular text editor, then copying it back into place when done. Otherwise, use a simple text editor like vim by executing sudo vim /etc/mysql/my.cnf.
Note: modify the above path to match the config file's real location - it's possible that it's actually in /etc/mysql/mysql.conf.d/mysqld.cnf
The following manual tweaks should be made out of the box. As per these tips, add this to the config file under the [mysqld] section:
innodb_buffer_pool_size = 1G # (adjust value here, 50%-70% of total RAM)
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 1 # may change to 2 or 0
innodb_flush_method = O_DIRECT
innodb_buffer_pool_size - the buffer pool is a storage area for caching data and indexes in memory. It's used to keep frequently accessed data in memory, and when you're running a dedicated or virtual server where the DB will often be the bottleneck, it makes sense to give this part of your app(s) the most RAM. Hence, we give it 50-70% of all RAM. There's a buffer pool sizing guide available in the MySQL docs.innodb_flush_log_at_trx_commit is explained here and indicates what happens with the log file. With 1 we have the safest setting, because the log is flushed to disk after every transaction. With 0 or 2 it's less ACID, but more performant. The difference in this case isn't big enough to outweigh the stability benefits of the setting of 1.innodb_flush_method - to top things off in regards to flushing, this gets set to O_DIRECT to avoid double-buffering. This should always be done, unless the I/O system is very low performance. On most hosted servers like DigitalOcean droplets you'll have SSDs, so the I/O system will be high performance.There's another tool from Percona which can help us find the remaining problems automatically. Note that if we had run it without the above manual tweaks, only 1 out of 4 fixes would have been manually identified because the other 3 depend on user preference and the app's environment.
Continue reading %How to Optimize MySQL: Indexes, Slow Queries, Configuration%