Archive for category: Random Stories

Original Source: https://www.smashingmagazine.com/2018/07/persuasion-user-experience-design/

So You Want to Persuade Users? Make Things Simple!

So You Want to Persuade Users? Make Things Simple!

Lyndon Cerejo

2018-07-17T16:15:38+02:00
2018-07-17T15:48:55+00:00

(This article is kindly sponsored by Adobe.) The persuasive design toolbox is filled with powerful tools based on psychology. These tools range from Cialdini’s set of six principles of persuasion to ten times that number of Persuasive Patterns. Presented with all these methods, it can be tempting to use all of them to cover all possible bases, using a shotgun approach, hoping that one will resonate with your target users.

However, applying persuasion principles and patterns in a haphazard manner just ends up being persuasive design clutter. Like user experience design, designing for everyone is designing for no one. Randomly thrown together persuasive techniques will also make users feel manipulated, not in control, making them abandon the site or experience. The key to persuading your users is to keep it simple: using focused persuasive techniques and tactics that will work for your users.

Persuasion Funnel

AIDA is an acronym used in marketing and advertising to describe the stages that a customer goes through in the purchase process. The stages of Attention, Interest, Desire and Action, generically follow a series of cognitive (thinking) and affective (feeling) stages culminating in a behavioral (doing e.g. purchase or trial) stage. This should sound familiar since this is what we do through design, especially persuasive design.

When it comes to persuasive design, users go through a few stages between Awareness and Action, and the design should guide them from one stage to the next. I don’t have a clever acronym for it (yet), but the stages the design has to take the users through are:

Awareness
Relevant
Credible
Usable
Desirable
Persuasive
Action

(Large preview)

When users are contemplating an action (like booking a hotel room), they have to be aware of your site, app, or experience. Once they begin their journey on your site, they quickly evaluate the experience and either proceed to the next step or leave and go elsewhere. With fewer users continuing to subsequent stages, the number of users at each stage begins to resemble the shape of a funnel as shown above.

Let’s peek inside what could be going on in hypothetical users’ minds as they go through the experience of booking a hotel room for New Year’s Eve in Times Square, and some of the reasons they may drop off in each stage.

Awareness

“Hmmm… Where do I start? Hotel chains promise the lowest rate if we book directly with them, but I won’t be able to see other hotel options around Times Square. Hotel… Maybe I should try an online travel agency like Trivago (looks like the Trivago guy / Trivago girl advertising works!) to find a wider range of hotels. I’m going to also quickly Google it to see if there are other options.”

Users have to be aware of your site, app or experience to use it — Duh!

Relevant

“I found HotelTonight on Google. It looks like a great way to get rooms last minute, but not this far in advance — it’s not relevant to me.”

If your experience is not relevant to the task they are trying to accomplish, users will leave and try elsewhere. If your products or services are relevant, but not findable by the user, work on your navigation, search, and content layout to ensure your products and services are visible. Everything does not have to be one click away, but if the user gets the scent of information, or cues that make them think they are on the right path, they will follow the trail to that information.

Credible

“This design looks like it hasn’t been updated since the [GeoCities era](http://www.arngren.net/).

— Warning bells go off in head —

I’m out of here.”

Users are aware of many of the risks available online and look for trust indicators including a known brand and domain, secure site, professional design, real-world contact information and third-party certificates or badges. Incorporate these elements to create a comfort level for the user.

Usable

“I can’t figure out where things are in the navigation, and the search results had hundreds of unhelpful results. The homepage has nice big images, but that meant I had to scroll before I could see any real content.”

Usability is surprisingly still an issue with many sites. Follow User Experience best practices during design, and test with users to validate that the design is usable.

Desirable

“This reminds me of Craigslist — it is usable, but the design does not make me want to stay and use it. I’ll try that other hotel website that provides an immersive, interactive experience as I search for hotels.”

As much as we like to believe it, users’ decisions are not always rational, and very often driven by emotion, and we can address that through design. Usability is about making it work well; this is about making it beautiful as well.

In his book Emotional Design, Don Norman explains: “Attractive things do work better — their attractiveness produces positive emotions, causing mental processes to be more creative, more tolerant of minor difficulties.” Don talks about the three different aspects of design: visceral, behavioral, and reflective. Visceral design is about appearance, behavioral about the pleasure and effectiveness of use, and reflective design involves the rationalization and intellectualization of a product.

Persuasive

“Oh, Wow! That’s a long list of hotels, with plenty of availability for New Year’s Eve. There’s no real reason to book now. I’ll just come back to book after Thanksgiving…”

The user was interested, able, and willing, but the design did not motivate him to take intended action. Use relevant persuasion techniques that apply to your user to move them toward the desired action.

Examples of persuasive methods while shopping on Travelocity for a hotel room for New Year’s Eve. (Large preview)

Action

“Oh, Wow! 65% of hotels are already booked in this area for New Year’s Eve. I better make a reservation now. . This looks like a nice hotel, and it also offers free cancellation – I’m reserving it now!”

The user who made it to this stage was interested, able, and willing, and the design nudged him to take intended action of making a reservation before leaving the site.

Persuasion is not about applying all available principles and patterns to your designs, but systematically identifying how you can address users’ barriers and motivators during each step of the journey, and guiding your users through the funnel to take the desired action.

The KISS Approach

Most of us are familiar with the acronym KISS: “Keep It Simple, Stupid,” a principle advocating simplicity as a key goal in design by avoiding unnecessary complexity. Let’s borrow that acronym for a 4-step approach to persuasive design.

Know The Right Behavior To Target

The first step is knowing the behavior you would like to target, and identifying the simplest action that can lead to that behavior change. Take the example of term life insurance companies who, to put it very bluntly, stand to benefit if their policyholders are healthy and don’t die while the policy is active. While those companies have a long-term ambitious goal of helping their policyholders lead healthy lives (mutually beneficial), that could be broken down into a simpler target behavior of walking 10,000 steps daily. This behavior is simple to understand, achieve, measure, and contributes to the long-term goal of healthier policyholders.

One such insurance company is offering new policyholders the latest Apple Watch for a low initial down payment ($25). The ongoing monthly payments can be waived each month that the policyholder leads an active lifestyle and exercises regularly (e.g. walks about 10,000 steps a day). About half the people who participated have achieved monthly goals, despite potential privacy implications.

John Hancock Term Life Insurance Apple Watch offer targets walking about 10,000 steps a day. (Large preview)

Identify Barriers And Motivators

User research for persuasive design digs below the surface thinking level to the feeling level, and moves beyond the rational to the emotional level, as shown below. Getting to know your users at a deeper level will help you use psychology to focus your design to get users to engage in the target behavior identified above. User interviews that focus on users’ feelings and emotions are used to uncover barriers and motivators they consciously or subconsciously face while trying to achieve the target behavior. This helps us identify which blocks we need to weaken, and which motivators we should strengthen, through persuasive design techniques and tactics.

(Large preview)

Simplify The Experience

Simplify the design experience of the first stages of the funnel, as users go through the mental verifications of relevancy, credibility, and usability of the experience. This includes making it easy for the user to find what they are looking for, credibility indicators like professional design, contact information, and third-party certificates or badges, as well as addressing usability issues. As Steve Krug put it very succinctly: “Don’t Make Me Think”.

Select Appropriate Triggers

Users who have made it this far in the process are interested in something you have to offer. As a designer, you have to nudge them to take the desired action. A good starting point is Robert Cialdini’s, six key principles of persuasion:

Reciprocity
People are obliged to give something back in exchange for receiving something.
Scarcity
People want more of those things they can have less of.
Authority
People follow the lead of credible, knowledgeable experts.
Consistency
People like to be consistent with the things they have previously said or done.
Liking
People prefer to say yes to those that they like.
Consensus (Social Proof)
Especially when they are uncertain, people will look to the actions and behaviors of others to determine their own.

These principles can be applied through dozens of different persuasive design patterns and methods, some of which have been previously published on Smashing Magazine (patterns, triggers), or in the books listed in the resources at the end. As you may notice, many persuasive patterns are related to UI patterns, because part of persuasion is reducing friction and simplifying what the user needs to do at any given point in time. For example, the persuasive pattern of Limited Choice can be realized through UI Pattern of Progressive Disclosure.

Given that there are dozens of patterns and methods (depending on where you look), it is important to selectively use methods that will resonate with your users. Applying all design patterns in the hope of some working will result in persuasion clutter and overwhelm the user, possibly driving them away from your site.

Examining Persuasion

Let’s take a closer look at the earlier example of the term life insurance through the eyes of someone who is motivated (shopping for life insurance) and has the ability (to pay monthly life insurance cost). Like me, let’s assume that this user was made aware of this through a sponsored post on Facebook. During the stages of awareness and relevance, there are a few persuasive triggers as shown below that make the user click “Learn More”.

(Large preview)

Clicking the “Learn More” button takes the user to a landing page that we will examine in sections for a persuasive flow:

(Large preview)

The user’s primary motivation in shopping for term life insurance is: “Protect Family,” and a big barrier is “High Cost.”

Reputable Name (Credibility)
Even if you’ve not heard of this company, John Hancock is a famous person and the term used as a synonym in the United States for one’s signature. The company reinforces it’s longevity later on the page.
Toll-free Number (Credibility)
Established and legitimate organization.
Message Framing
Live healthy, is also reinforced by the image of a family enjoying outdoors.
“This life insurance product will help me live longer, lead a happy life like them, and protect my family in case something happens, and won’t cost much.”
People Like Me & Association
This family looks like mine (or the family next door) — I can see myself in this wide-open field (visceral and reflective triggers).
Extrinsic Reward
An Apple watch for $25 — that’s a bonus here!
Visual Cueing
The person in focus (stereotypical breadwinner) has his gaze directly focused at the form below, leading the user to the next step.
Foot In The Door
This quote won’t cost anything — zip, nada.
Computer As A Social Actor
The information takes a conversational tone and format, not the usual form in rows and columns. The information seems reasonable to generate a quote.
Commitment & Consistency
By filling this quick, easy, and free form, chances are that the user will act consistently and proceed when it comes to the next step (application), unless there’s another barrier (price, benefits, etc.)

(Large preview)

Control
The user has a choice of devices.
Extrinsic Rewards
More rewards to be earned.
Control
The user controls how much they pay (the more active, the less you’ll pay). Also, in case the user does is not active, the cost is framed as just $13 (for a month).
Credibility
The company reinforces longevity and protector of America.
Authority
Licensed Coverage Coach (not just a sales agent).
Flow
One way to keep users in the flow and not get distracted is by disabling the social media links (which could raise the question: why display them?).

That took longer to dissect and read than it does in real life, where most of this is processed consciously and subconsciously in a few seconds, often with a glance or two.

Apart from the methods establishing credibility, the persuasive methods are used to strengthen the primary motivator of “Protect Family” (get insurance, extrinsic reward will help me live longer for my family), and weaken the barrier of “High Cost” (low monthly cost, additional savings, no ongoing watch payments). Note how they work together and don’t conflict or clutter the experience.

Conclusion

Persuasion is all around us, in our everyday lives. As designers, we can use ethical persuasive design methods to get users to take some action. With plenty of persuasive methods available, we have to be selective about what we use. We can use the KISS approach to keep it simple:

Know the right behavior to target
Identify barriers and motivators
Simplify the experience
Select appropriate triggers

KISS also reminds us to Keep It Simple & Straightforward, by selecting a simple target behavior, simplifying the experience for the user, and by applying persuasive techniques that will lead to the target behavior without overwhelming the user.

Further Reading

“Neuro Web Design: What Makes Them Click?,” Susan Weinschenk
“Design for the Mind: Seven Psychological Principles of Persuasive Design,” Victor S. Yocco
“Influence: The Psychology of Persuasion, by Robert B. Cialdini
“Persuasive Technology: Using Computers to Change What We Think and Do,” B.J. Fogg
“Persuasive Design Patterns (scroll down the page),” UI-Patterns
“Persuasive Patterns Card Deck,” UI-Patterns

This article is part of the UX design series sponsored by Adobe. Adobe XD tool is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype, and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance, and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.

(yk, il)

Original Source: https://www.smashingmagazine.com/2018/07/writing-code-poems/

Learning To Code By Writing Code Poems

Learning To Code By Writing Code Poems

Murat Kemaldar

2018-07-11T14:00:32+02:00
2018-07-17T15:48:55+00:00

Back in 2008, I started studying design and clearly remember how the sheer sight of code just intimidated me. I had some coding classes, and without any prior coding experience, I had a tough time understanding the code I first got in touch with. Suddenly, the words that I was used to in the English language (such as “new,” “return” and “throw/catch”) took on a whole new meaning; the cryptic syntax, semicolons, brackets and completely new rules didn’t make things any easier for me.

If you are new to JavaScript and/or have struggles adding it to your skillset, I may have an approach for you to overcome those barriers. You are definitely not alone, and you have every right to think that learning to code is a tough nut to crack.

Why Is Learning To Code So Tough?

Here are some of the misconceptions about why I think people are having a hard time learning or getting interested in JavaScript (or any coding language):

Code is cryptic, purely functional and scary;
Code is meant for machines only, so people do not feel addressed or engaged;
Code is not treated as a language because it has a completely different use case and looks very different from anything they have seen before;
People think of stereotypes (evil hackers, maybe some Matrix dudes), and thus do not identify themselves with it.

Nope, we can’t do any magic tricks, but we have articles, books and webinars featuring techniques we all can use to improve our work. Smashing Members get a seasoned selection of magic front-end tricks — e.g. live designing sessions and perf audits, too. Just sayin’! 😉

Explore Smashing Wizardry →

Me, before any contact with code (Large preview)

As a developer, you are expected to treat code in a very specific way — even to think in a quite different (and highly logical) way. Coding languages are quite strict and intolerant; a single character can make the machine fail to understand what you mean and make applications crash. You are expected to ignore and override certain things you know from speaking and writing a human language (which is, by the way, also the case when learning a new human language).

But not all programming languages, documentations or tutorials on the web are made with this “human to programming language transition” in mind. Of course, they don’t have to. After all, the main purpose of code is to tell machines what to do.

Still, due to that purpose, a chance for comparison is simply missing and the languages you speak (vocabulary and rules) seem to be rendered useless for learning a programming language. There is no word for “love” in the JavaScript language, nor does it make sense to say “I love you.” A machine (or browser) simply does not know or care about love (yet?). This “completely new” and “don’t know where to start” feeling can be scary as hell.

Me, after my first contact with code. (Large preview)

This is why I am here. I think that you can learn JavaScript in a much easier and artistic fashion, by holding on to your human language knowledge, and by treating JavaScript like any other human language. Let me demonstrate with a small example.

Fun fact: Some programming languages actually have the transition from one programming language to another in mind. This is why it is so much easier to learn a lot of programming languages — just by learning a single one.

A Small Example

In a lot of cases, when you want to execute JavaScript code, you want the “document” (basically the website, a user is downloading on each visit) to be ready so that you can interact with HTML elements, for example. In pure JavaScript, you may stumble over something this:

(function() {
// Your code goes here
})();

(Yuck! ? In this case, a function is defined in brackets, and then immediately called with another pair of brackets at the end. This is referred to as an IIFE.)

Or sometimes like this:

if (document.readyState === ‘complete’) {
// Your code goes here
}

The first snippet definitely requires an explanation, while with the second (and maybe some fantasy), one could comprehend that there is a condition which needs to be fulfilled so that something else happens just by just looking at it.

Imagine something like this, though:

onceUponATime(function () {
// Your code (story) goes here
})

“Once upon a time” is something (dare I say) even a child might understand. It addresses the developer (by referring to childhood memories), while theoretically doing the same thing. This is what I consider “having the human to coding language transition” in mind.

Quick note on “functions“: A function is basically a skill, which is dormant until you call upon it. “To read” is a skill function read() { … }, which is called upon when you are want to read something like this: read(). There is also something called “anonymous functions”, i.e. "function() { … } (has no name, like in the snippets above) which are basically “one-time / casual actions” that you wouldn’t consider to be a skill, such as “to push a button.”

Turning The Tables: From Message To Basics

So let’s take this idea a bit further. Let’s take the reasons and misconceptions above, and turn them upside-down:

A small poem.

Written in JavaScript.

Made for human beings.

About the love between two individuals.

// Love at first sight
if (me.getDistanceTo(you.position) < 200) {
me.setFeelings({
inLove: true,
});
}

It is not functional. It is currently not meant for machines. It is meant for you to read and understand.

If you got the message of the poem, you actually understood a piece of JavaScript code, which you might have compared to the English language.

Now you might ask yourself: I understand this, but why is it written like this? What are the rules (grammar) of this language? What is the meaning of “me” (in a technical sense), and why does this code look so similar to English?

Rules, Vocabulary, And Variables

One of the most important things to understand when learning a programming language is the concept of variables.

Every human language has its rules (grammar) and a lot of vocabulary (pre-defined). Obviously, both of these first need to be learned in order to be able to speak the language.

JavaScript, like many other programming languages, also comes with its own set of rules (e.g. the . between the words or how if statements are written) and its own vocabulary (if, document, window, Event, and so on). These keywords are reserved (or ‘pre-defined’) by JavaScript (and the browser), and each one of them has its specific purpose.

But like I mentioned earlier, a chance to compare the words and sentences you know from the English language is seemingly missing because there are no equivalents.

This is where variables come in; you (the developer) can (or even have to) define the variables in order to make machines and developers understand what something stands for. Variables can take a lot of forms (hence the name): They can be a chain of words and letters (strings), a number, an action (function), or even a collection (array). You name it.

In all languages, there is probably a word for love. You kinda know what it means, but not really, because it is so subjective. But still, there is a word for it.

But in JavaScript, there is no “love,” until you say there is. It can be whatever you want it to be.

var love = {
color: ‘red’,
duration: 365,
loveTarget: ‘cats’,
};
// a simple variable expression,
// where love is an object “{ … }”, a thing
// with some properties (color, duration, loveTarget).

const love2 = {
color: ‘purple’,
duration: ‘forever’,
loveTarget: ‘dogs’,
};

// also a variable expression, where love2 (a constant),
// cannot be redefined / overwritten completely:
// love2 = undefined; // => will not work

// (“undefined” is a pre-defined javascript keyword,
// basically saying “has no value”)

It is crucial to be able to distinguish between what is pre-defined in JavaScript (JavaScript rules and vocabulary), and what is actually custom defined by the developer (also known as ‘application logic’ or ‘business logic’).

Returning to the poem written above:

// Love at first sight
if (me.getDistanceTo(you.position) < 200) {
me.setFeelings({
inLove: true,
});
}

These expressions come from the following JavaScript vocabulary/ruleset:

if (…) { … }
// if statement: when … is met, do things in { … }

{
inLove: true,
}
// an “object” with some info, some thing in the world.
// can contain other info, and “skills” (functions).
// “inLove” is a custom property,
// “true” is pre-defined in javascript, (meaning: “yes”)
// and the value of “inLove”.

.
// needed to access an objects property “my name: me.name”

getDistanceTo()
// an expression to “call” a function (a “skill”).
// getDistanceTo is custom (not JavaScript), and a function,
// so it can be executed / called upon with the “()” after.
// sometimes you can pass arguments in those brackets (like “position”)
// to change the outcome of a function.

And these are the variables (where you have free reign over defining their names and behavior):

me // an object, some thing in the world
you // an object, some thing in the world
position // an info about “you”, accessed by the “.”
getDistanceTo // a skill of me, accessed by the “.”
getDistanceTo() // the skill, with javascript grammar telling: do it.
getDistanceTo(position) // same, but do it with “position”.
setFeelings // another skill of me, accessed by the “.”
setFeelings({ inLove: true }); // the skill, with some instructions (an object).

Let’s assume the poem is now human-readable. You might have understood the message, you also might see the difference between JavaScript language rules you need to follow, and the things you actually have to come up with yourself (the variables).

But what about the machine?

If the machine (the browser) were to read this poem, it would throw an error. The machine needs a definition of “me” and “you” because it tries to access its properties (via the . in me.getDistanceTo()). With the distinction ability mentioned above, you can actually engineer “me” and “you” to make the poem executeable/machine-readable, like this:

// This is how the definition of a being (me/you) could look like

var me = {
position: {x: 0, y: 0} // some coordinates, maybe
getDistanceTo: function(position) {
// calculate the distance, relative to own position
},
setFeelings: function(feelings) {
// handle those feelings…
}
}

var you = {
position: {x: 0, y: 0} // some coordinates, maybe
}

// the poem itself
if (me.getDistanceTo(you.position) < 200) {
me.setFeelings({
inLove: true,
});
}

So what happened here?

We read a JavaScript poem, written with JavaScript “grammar” with the only goal to be understood by human beings.
After understanding the message, we distinguished between rules, vocabulary, and variables, to understand the structure of the poem (grammar and basics of JavaScript).
With that distinction, we engineered the rest of the poems variables, with JavaScript rules in order to make it runnable by a machine (in the browser).

This was possible, because we treated JavaScript just like the English language.

A Bigger Example: Interactive Code Poetry

This is how my personal project LoveBits came to be. LoveBits is a code learning/storytelling experience.

LoveBits: Code poetry project in JavaScript (Large preview)

It tries to get people interested in JavaScript/coding by:

Putting readability and human language first;
Combining code with an art the reader might already be familiar with.

Storywise, it is about two Bits (rectangular beings); one of the Bits (blueBit) is the romantic one and writes JavaScript love poems to the other Bit (purpleBit).

When you start LoveBits, you can select one of the multiple love poems (written in JavaScript). Each poem has a code snippet which is written in a way that it is supposed to be understood by people who are not even familiar with programming. The only requirement is the English language.

“Love at first sight” (actually one of the LoveBits poems), for example, is about these two Bits in which the blueBit basically says, “If I get close enough to your position, I will ‘set my feelings’ to inLove: true.”

The special thing about these poems though is that you can “run” or “play” them simply by pressing the “play” button below. In the case of “Love at first sight,” you would see a blue and purple rectangle along with a number. As you might’ve already guessed, those are the two Bits mentioned in the poem, and the number below the blueBit is actually the distance between the blueBit and the purpleBit.

As the poem suggests, you may want to make the blueBit fall in love with the purpleBit by reducing the distance between them, right? So what can you do? You can interact and drag the blueBit around, and make it fall in love. But be careful, sometimes there is more than just one outcome.

One might actually say that you are the machine here. You’re the one who needs to interpret JavaScript code to be able to act and help two digital beings fall in love.

Where To Go From Here?

If you are a struggling developer, try treating JavaScript like a human language, and just understand what code snippets are supposed to do first instead of what they actually end up doing.

This is what I would recommend you to do next:

Always prefer going straight for examples and code for entire applications that combine rules, vocabulary, and variables together to form an application logic;
Application logic will tell the stories that will help you fill the gaps like in the code examples above. Code libraries and utilities such as lodash will only provide you with new vocabulary which will become helpful after being able to read and understand JavaScript code;
Review existing code, and try to break it down into small functions with names that reflect what they do. Write code which addresses humans and machines alike. Write code in such a way that it can be read like a sentence. Use comments wherever needed. Think about: How would I express this in a human language (to another developer)?

Conclusion

Learning to code can become easier once you start treating code as a human language and not as something aliens may have invented. Learning to distinguish between language features (built-ins) and variables/custom code for application logic is crucial. Being able to understand the application logic will put you in a powerful position to improve and change things, without even knowing language features.

Message before basics: Understand the message of any code snippet, and the basics of JavaScript will naturally follow. How many times have you heard someone say, “I understand the language, but I do not speak it yet”? It is a natural process, which can and maybe should be applied for learning both human and coding languages.

Also, always keep in mind that code has a clear functional purpose, but it does not always have to be like that. Even human languages were purely functional once, but then there came poems and even songs (JavaScript songs, anyone?), which connected people in entirely different ways. I think, or hope, that the same can apply here.

Always explore code projects, and perhaps even try writing a poem yourself (maybe even in another programming language you are familiar with)? I enjoyed creating the LoveBits project and would love to see some of your ideas in the comments below!

Further Reading

“If Hemingway wrote JavaScript,” Angus Croll
This is one of my favorite books which I actually stumbled upon after LoveBits. It’s about several famous poets and artists, and how they would have written JavaScript code snippets. It’s hilarious!

(rb, ra, il)

Original Source: https://www.sitepoint.com/building-ethereum-dapps-whitelisting-testing-story-dao/

In part 3 of this tutorial series on building DApps with Ethereum, we built and deployed our token to the Ethereum testnet Rinkeby. In this part, we’ll start writing the Story DAO code.

We’ll use the conditions laid out in the intro post to guide us.

Contract Outline

Let’s create a new contract, StoryDao.sol, with this skeleton:

pragma solidity ^0.4.24;

import “../node_modules/openzeppelin-solidity/contracts/math/SafeMath.sol”;
import “../node_modules/openzeppelin-solidity/contracts/ownership/Ownable.sol”;

contract StoryDao is Ownable {
using SafeMath for uint256;

mapping(address => bool) whitelist;
uint256 public whitelistedNumber = 0;
mapping(address => bool) blacklist;
event Whitelisted(address addr, bool status);
event Blacklisted(address addr, bool status);

uint256 public daofee = 100; // hundredths of a percent, i.e. 100 is 1%
uint256 public whitelistfee = 10000000000000000; // in Wei, this is 0.01 ether

event SubmissionCommissionChanged(uint256 newFee);
event WhitelistFeeChanged(uint256 newFee);

uint256 public durationDays = 21; // duration of story’s chapter in days
uint256 public durationSubmissions = 1000; // duration of story’s chapter in entries

function changedaofee(uint256 _fee) onlyOwner external {
require(_fee < daofee, “New fee must be lower than old fee.”);
daofee = _fee;
emit SubmissionCommissionChanged(_fee);
}

function changewhitelistfee(uint256 _fee) onlyOwner external {
require(_fee < whitelistfee, “New fee must be lower than old fee.”);
whitelistfee = _fee;
emit WhitelistFeeChanged(_fee);
}

function lowerSubmissionFee(uint256 _fee) onlyOwner external {
require(_fee < submissionZeroFee, “New fee must be lower than old fee.”);
submissionZeroFee = _fee;
emit SubmissionFeeChanged(_fee);
}

function changeDurationDays(uint256 _days) onlyOwner external {
require(_days >= 1);
durationDays = _days;
}

function changeDurationSubmissions(uint256 _subs) onlyOwner external {
require(_subs > 99);
durationSubmissions = _subs;
}
}

We’re importing SafeMath to have safe calculations again, but this time we’re also using Zeppelin’s Ownable contract, which lets someone “own” the story and execute certain admin-only functions. Simply saying that our StoryDao is Ownable is enough; feel free to inspect the contract to see how it works.

We also use the onlyOwner modifier from this contract. Function modifiers are basically extensions, plugins for functions. The onlyOwner modifier looks like this:

modifier onlyOwner() {
require(msg.sender == owner);
_;
}

When onlyOwner is added to a function, then that function’s body is pasted into the part where the _; part is, and everything before it executes first. So by using this modifier, the function automatically checks if the message sender is also the owner of the contract and then continues as usual if so. If not, it crashes.

By using the onlyOwner modifier on the functions that change the fees and other parameters of our story DAO, we make sure that only the admin can do these changes.

The post Building Ethereum DApps: Whitelisting & Testing a Story DAO appeared first on SitePoint.

Original Source: https://www.hongkiat.com/blog/50-most-beautiful-blogger-templates/

An updated list of beautiful yet advanced Blogger (Blogspot) templates free to download.

The post 50 Most Beautiful Blogger Templates to Download (2018) appeared first on Hongkiat.

Visit hongkiat.com for full content.

Original Source: http://feedproxy.google.com/~r/Designrfix/~3/R12VbSw7AsM/ultimate-front-end-development-bundle

So you want to become a web developer? Well, you made the right choice. As we progress towards a more tech-filled future, the demand for web developers is increasing. Companies are upping the salary to ensure that they hire the best talent out there. The good news is that you don’t need a degree to […]

The post 96% Off: Get The Ultimate Front End Development Bundle for $39 appeared first on designrfix.com.