Testing Mines

Tuesday, September 20, 2016

Guide to Building a Top Web Design Portfolio

Writer's Note: This is the first of a series of portfolio guides written to enhance each designer, depending on their particular set of skills. Enjoy!


A portfolio is a very important link between a designer and a client. It aims to impress a potential client by showing the designer’s work and skills. At Toptal, we screen a lot of web designers and review a lot of portfolios. Creating a top web design portfolio is by no means easy, even for experienced designers. We’re sharing our tips to help you create a top portfolio.

1. Content Is King

Most web designers are no strangers to the concept of content first. Content is king in web design, so why not apply that same concept to your portfolio? Make content the star of the show and focus on the quality of the message you are trying to get across. Try to avoid eye candy in the images you use and concentrate on engaging potential customers through the statement you are making. This is not to say you should neglect the images — after all, they will without a doubt attract clients and open a few doors — but the copy is likely to make you the ideal candidate for a job. Without great copy, there’s no top portfolio. As a result, you might easily appear less professional and the client could choose a different designer. Well-written content is your best chance to communicate your skills and expertise and sell your work to a future employer.

2. Take Your Target Audience Into Account

Another well-known web design strategy is not to think of yourself (the web designer) as the user. As you would with a web design project, think of your target audience and their wants, needs, and possible limitations. Put yourself into the shoes of the people who will be viewing your portfolio, find pain points and fix them. Help them understand the message you are sending.
Remember that a portfolio is about projects, so aim to find the right balance and remove everything that gets in a way of a clear, concise message. The goal of a portfolio is to showcase your work to potential clients and impress them. They need to find a quick and easy path to the information they want, so think of a way to provide just that.

3. Tell a Story

Engage potential clients by telling a story. For instance, explaining the process behind a project could come a long way. Showcase not only a finished product but also the way you solve real problems. This will help clients appreciate the time and effort invested behind the scenes and get to know you as a web designer. Explain your role in the project and mention the techniques and technologies used to demonstrate the value of your work. Your skills should be reflected in the images you provide.
If you were a member of a team, mention and promote the success of the entire team and the project, not only your role. Are there some detailed UI problems you solved which you can share? What deliverables were produced and why? Which of the major KPIs can be used to demonstrate project goals and success? Was there a part of the project that was not a success and why was that the case? Try to be objective and honest — not every step of the project is without flaws and no web designer is error free. Honesty might just be the best policy and it might impress clients. While you could do all this in a Skype meeting with a potential employer, why not save yours and their time and tell a story in your portfolio? It’s a definite win-win situation.

4. Don’t Make Your Clients Think

“Don’t make me think” by Steve Krug is one of the most famous web design books and, generally speaking, lessons in web design. Avoid being vague to let clients accomplish their task without hitting roadblocks. Make sure your work, as well as personal and contact information is easy to understand and digest. Present goals, results, and features in a direct and concise, intuitive fashion. If your project is live, make sure to provide a link to the website and let the client discover more. The browser is the natural environment for any website, so it only makes sense to let clients view your project in it. If the project is not online, maybe you can provide a link to a detailed case study, a front-end prototype, or a style guide. This might be your only opportunity to make a lasting impression, so invest extra effort.

5. Be Professional

The final tip may be obvious, but is by no means insignificant: be professional in your presentation. Assure clients you are not willing to gamble with the quality of their projects.
There is a number of ways you can do this. Here are a few:
  • Use spell-check software to avoid spelling errors and come off superficial.
  • Consider specifying the start and end dates to provide additional information and add to the credibility.
  • Optimize images without sacrificing quality — no-one wants to see pixelated images, but no-one wants to wait for them to load, either. After all, we’re web designers and therefore no strangers to image optimizations.
  • Be honest when stating your work experience and job title.
  • Give credit where credit is due. If other agencies and team members were involved in a project, mention them and their role.
  • Select only your strongest portfolio pieces — quality will always win over quantity and you may well be judged by your weakest work.
  • If the project was a success, ask the client for a testimonial and add it to your portfolio.
  • Ask peers for a review to find ways of improving your portfolio.
  • Much like any website, your portfolio is never finished, so remember to update it regularly and keep improving it.
This wraps up our tips for creating a top web design portfolio.

Source: Toptal

Wednesday, September 14, 2016

Top 10 Most Common Mobile App Design Mistakes

The mobile app market is saturated with competition. Trends turn over quickly, but no niche can last very long without several competitors jumping onto the bandwagon. These conditions result in a high failure rate across the board for the mobile app market. Only 20% of downloaded apps see users return after the first use, whereas 3% of apps remain in use after a month.
If any part of an app is undesirable, or slow to get the hang of, users are more likely to install a new one, rather than stick it out with the imperfect product. Nothing is wasted for the consumer when disposing of an app - except for the efforts of the designers and developers, that is. So, why is it that so many apps fail? Is this a predictable phenomenon that app designers and developers should accept? For clients, is this success rate acceptable? What does it take to bring your designs into the top 3% of prosperous apps?
The common mistakes span from failing to maintain consistency throughout the lifespan of an app, to attracting users in the first place. How can apps be designed with intuitive simplicity, without becoming repetitive and boring? How can an app offer pleasing details, without losing sight of a greater purpose? Most apps live and die in the first few days, so here are the top ten most common mistakes that designers can avoid.
Only 3% of mobile apps are in use after being downloaded.Only 3% of mobile apps are in use after being downloaded.

Common Mistake #1: A Poor First Impression

Often the first use, or first day with an app, is the most critical period to hook a potential user. The first impression is so critical that it could be an umbrella point for the rest of this top ten. If anything goes wrong, or appears confusing or boring, potential users are quickly disinterested. Although, the proper balance for first impressions is tricky to handle. In some cases, a lengthy onboarding, or process to discover necessary features can bores users. Yet, an instantly stimulating app may disregard the need for a proper tutorial, and promote confusion. Find the balance between an app that is immediately intuitive, but also introduces the users to the most exciting, engaging features quickly. Keep in mind that when users are coming to your app, they’re seeing it for the first time. Go through a proper beta testing process to learn how others perceive your app from the beginning. What seems obvious to the design team, may not be for newcomers.

Improper Onboarding

Onboarding is the step by step process of introducing a user to your app. Although it can be a good way to get someone quickly oriented, onboarding can also be a drawn out process that stands in the way of your users and their content. Often these tutorials are too long, and are likely swiped through blindly.
Sometimes, users have seen your app used in public or elsewhere, such that they get the point and just want to jump in. So, allow for a sort of quick exit strategy to avoid entirely blocking out the app upon its first use. To ensure that the onboarding process is in fact effective, consider which values this can communicate and how. The onboarding process should demonstrate the value of the app in order to hook a user, rather than just an explanation.

Go easy on the intro animation

Some designers address the issue of a good first impression with gripping intro animations to dazzle new users. But, keep in mind that every time someone wants to run the app, they’re going to have to sit through the same thing over and over. If the app serves a daily function, then this will tire your users quickly. Ten seconds of someone’s day for a logo to swipe across the screen and maybe spin a couple times don’t really seem worth it after a while.

Common Mistake #2: Designing an App Without Purpose

Avoid entering the design process without succinct intentions. Apps are often designed and developed in order to follow trends, rather than to solve a problem, fill a niche, or offer a distinct service. What is the ambition for the app? For the designer and their team, the sense of purpose will affect every step of a project. This sensibility will guide each decision from the branding or marketing of an app, to the wireframe format, and button aesthetic. If the purpose is clear, each piece of the app will communicate and function as a coherent whole. Therefore, have the design and development team continually consider their decisions within a greater goal. As the project progresses, the initial ambition may change. This is okay, as long as the vision remains coherent.
Conveying this vision to your potential users means that they will understand what value the app brings to their life. Thus, this vision is an important thing to communicate in a first impression. The question becomes how quickly can you convince users of your vision for the app? How it will improve a person’s life, or provide some sort of enjoyment or comfort. If this ambition is conveyed quickly, then as long as your app is in fact useful, it will make it into the 3%.
Often joining a pre-existing market, or app niche, means that there are apps to study while designing your own. Thus, be careful how you choose to ‘re-purpose’ what is already out there. Study the existing app market, rather than skimming over it. Then, improve upon existing products with intent, rather than thoughtlessly imitating.

Common Mistake #3: Missing Out On UX Design Mapping

Be careful not to skip over a thoughtful planning of an app’s UX architecture before jumping into design work. Even before getting to a wireframing stage, the flow and structure of an app should be mapped out. Designers are often too excited to produce aesthetics and details. This results in a culture of designers who generally under appreciate UX, and the necessary logic or navigation within an app. Slow down. Sketch out the flow of the app first before worrying too much about the finer brush strokes. Often apps fail from an overarching lack of flow and organization, rather than imperfect details. However, once the design process takes off always keep the big picture in mind. The details and aesthetic should then clearly evoke the greater concept.

Common Mistake #4: Disregarding App Development Budget

As soon as the basis of the app is sketched, this is a good time to get a budget from the development team. This way you don’t reach the end of the project and suddenly need to start cutting critical features. As your design career develops, always take note of the average costs of constructing your concepts so that your design thinking responds to economic restraints. Budgets should be useful design constraints to work within.
Many failed apps try to cram too many features in from launch.Many failed apps try to cram too many features in from launch

Common Mistake #5: Cramming in Design Features

Hopefully, rigorous wireframing will make the distinction between necessary and excessive functions clear. The platform is already the ultimate swiss army knife, so your app doesn’t need to be. Not only will cramming an app with features lead to a likely disorienting User Experience, but an overloaded app will also be difficult to market. If the use of the app is difficult to explain in a concise way, it’s likely trying to do too much. Paring down features is always hard, but it’s necessary. Often, the best strategy might be to gain trust in the beginning with a single or few features, then later in the life of the app can new ones be ‘tested’. This way, the additional features are less likely to interfere with the crucial first few days of an apps’ life.

Common Mistake #6: Dismissing App Context

Although the conditions of most design offices practically operate within a vacuum, app designers must be aware of wider contexts. Although purpose and ambition are important, they become irrelevant if not directed within the proper context. Remember that although you and your design team may know your app very well, and find its interfacing obvious, this may not be the case for first time users, or different demographics.
Consider the immediate context or situation in which the app is intended to be used. Given the social situation, how long might the person expect to be on the app for? What else might be helpful for them to stumble upon given the circumstance? For example, UBER’s interface excels at being used very quickly. This means that for the most part, there isn’t much room for other content. This is perfect because when a user is out with friends and needing to book a ride, your conversation is hardly interrupted in the process. UBER hides a lot of support content deep within the app, but it only appears once the scenario calls for it.
Who is the target audience for the app? How might the type of user affect how the design of the app? Perhaps, consider that an app targeted for a younger user may be able to take more liberties in assuming a certain level of intuition from the user. Whereas, many functions may need to be pointed out for a less tech savvy user. Is your app meant to be accessed quickly and for a short period of time? Or, is this an app with lots of content that allows users to stay a while? How will the design convey this form of use?
A good app design should consider the context in which it is used.A good app design should consider the context in which it is used.

Common Mistake #7: Underestimating Crossing Platforms

Often apps are developed quickly as a response to changing markets or advancing competitors. This often results in web content being dragged into the mobile platform. A constant issue, which you’d think would be widely understood by now, is that often apps and other mobile content make poor transitions between the desktop, or mobile platforms. No longer can mobile design get away with scaling down web content in the hope of getting a business quickly into the mobile market. The web to mobile transition doesn’t just mean scaling everything down, but also being able to work with less. Functions, navigation and content must all be conveyed with a more minimal strategy. Another common issue appears when an app developing team aspires to release a product simultaneously on all platforms, and through different app stores. This often results in poor compatibility, or a generally buggy, unpolished app.The gymnastics of balancing multiple platforms may be too much to add onto the launch of an app. However, it doesn’t hurt to sometimes take it slowly with one OS at a time, and iron out the major issues, before worrying about compatibility between platforms.

Common Mistake #8: Overcomplicating App Design

The famous architect Mies Van der Rohe once said, “It’s better to be good than to be unique”. Ensure that your design is meeting the brief before you start breaking the box or adding flourishes. When a designer finds themselves adding things in order to make a composition more appealing or exciting, these choices will likely lack much value. Continue to ask throughout the design process, how much can I remove? Instead of designing additively, design reductively. What isn’t needed? This method is directed as much towards content, concept and function as it is aesthetics. Over complexity is often a result of a design unnecessarily breaking conventions. Several symbols and interfaces are standard within our visual and tactile language. Will your product really benefit from reworking these standards? Standard icons have proven themselves to be universally intuitive. Thus, they are often the quickest way to provide visual cues without cluttering a screen. Don’t let your design flourishes get in the way of the actual content, or function of the app. Often, apps are not given enough white space. The need for white space is a graphic concept that has transcended both digital and print, thus it shouldn’t be underrated. Give elements on the screen room to breath so that all of the work you put into navigation and UX can be felt.
The app design process can be reductive, rather than additive.The app design process can be reductive, rather than additive.

Common Mistake #9: Design Inconsistencies

To the point on simplicity, if a design is going to introduce new standards, they have to at least be consistent across the app. Each new function or piece of content doesn’t necessarily have to be an opportunity to introduce a new design concept. Are texts uniformly formatted? Do UI elements behave in predictable, yet pleasing ways throughout the app? Design consistency must find the balance between existing within common visual language, as well as avoiding being aesthetically stagnant. The balance between intuitive consistency and boredom is a fine line.

Common Mistake #10: Under Utilizing App Beta Testing

All designers should analyze the use of their apps with some sort of feedback loop in order to learn what is and isn’t working. A common mistake in testing is for a team to do their beta testing in-house. You need to bring in fresh eyes in order to really dig into the drafts of the app. Send out an ad for beta testers and work with a select audience before going public. This can be a great way to iron out details, edit down features, and find what’s missing. Although, beta testing can be time consuming, it may be a better alternative to developing an app that flops. Anticipate that testing often takes 8 weeks for some developers to do it properly. Avoid using friends or colleagues as testers as they may not criticize the app with the honesty that you need. Using app blogs or website to review your app is another way to test the app in a public setting without a full launch. If you’re having a hard time paring down features for your app, this is a good opportunity to see what elements matter or not.
The app design market is a battleground, so designing products which are only adequate just isn’t enough. Find a way to hook users from the beginning - communicate, and demonstrate the critical values and features as soon as you can. To be able to do this, your design team must have a coherent vision of what the app is hoping to achieve. In order to establish this ambition, a rigorous story-boarding process can iron out what is and isn’t imperative. Consider which types of users your app may best fit with. Then refine and refine until absolutely nothing else can be taken away from the project without it falling apart.
This article was written by Kent Mundle, a Toptal Technical Editor.

Thursday, September 08, 2016

Software design pointers..........> - Kapil Sharma

• Before design and development any task, first ask these 5 things: Why, What, Whom, Where, When: (W-5 approach)

• A use case of design and develop of one complex service window for government departments, where all state departments services available online through CSC's (Common Services Centers) or mobile app or single website.

• Generally state IT projects are developed on ‘’Big-Bang’’ design approach. 

• Where all entities are build on one-go and got live as a singular unit. 

• Pros. of this approach is one big working system, multiple features, different services offering and catering large complex diversify population.

• Cons. with this system is failure in building complex system in one single go as multiple stakeholders are not compatible in one single linear system design approach, checks and balances are difficult to implement in one go, no functional SOP availability for multiple departments for getting in and out of system implementations. 

• For complex IT system where multiple stakeholders present, the agile block approach recommended. 

• One small feature or module developed and implemented in one go of development cycle of 2 to 3-week period. A small team of 3-9 people (developers, QA, DBA, PM) worked with stakeholder SOP and design and develop system and implement in max three-week time frame. Anything goes wrong in design or development can be redone or validated in 3-weeks times. If design redone required only 3 weeks’ time effected not as a whole project time frame got the hard hit. This small chunk approach saves time, money leads to less stress and provide more time for creative and effective design and development ideas. 

• For State IT projects, I think rather focusing on full big project we can break it into small modules and than start design and development in small chunks. 

• There are two best suited approaches.

• One is district wise development approach, where services are developed for one selected district and that district divided into two parts urban and rural. First focus on urban part, create effective online services only for urban area. After successful implementation do the data analysis and figure out analytics for service in high demand and other services demand than try to implement the clone of urban services into rural area, again redone the analysis and analytics cycle. 

• This same two area approach can be implemented in different districts and after 5+ districts data analytics, services can be optimized and more effective and more predictive services can be design and developed for future.

• The second design approach covers the complete state, but with one department at one time with all services in one go or incremental way. 

• After completing one department, then moves towards the next one. All departments first sorted out in the priority list for higher importance departments w.r.t public services offering.

My Linkedin: https://lnkd.in/fB4_EMX

Tuesday, September 06, 2016

Vital WordPress Questions and Answers

  1. Consider the following code snippet. Briefly explain what changes it will achieve, who can and cannot view its effects, and at what URL WordPress will make it available.
add_action('admin_menu', 'custom_menu');

function custom_menu(){
    add_menu_page('Custom Menu', 'Custom Menu', 'manage_options', 'custom-menu-slug', 'custom_menu_page_display');
}

function custom_menu_page_display(){
    echo '<h1>Hello World</h1>';
    echo '<p>This is a custom page</p>';
}
With default settings and roles, admins can view it and all lower roles can’t. In fact this menu item will only be visible to users who have the privilege to “manage options” or change settings from WordPress admin dashboard.
The admin custom page will be made available at this (relative) URL: “?page=custom-menu-slug”.
 
2. How would you change all the occurrences of “Hello” into “Good Morning” in post/page contents, when viewed before 11AM?
In a plugin or in theme functions file, we must create a function that takes text as input, changes it as needed, and returns it. This function must be added as a filter for “the_content”.
It’s important that we put a little effort to address some details:
  • Only change when we have the full isolate substring “hello”. This will prevent words like “Schellong” from becoming “sgood morningng”. To do that we must use “word boundary” anchors in regular expression, putting the word between a pair of “\b”.
  • Keep consistency with the letter case. An easy way to do that is to make the replace case sensitive.
<?php
function replace_hello($the_content){
    if(current_time('G')<=10){
        $the_content=preg_replace('/\bhello\b/','good morning',$the_content);
        $the_content=preg_replace('/\bHello\b/','Good Morning',$the_content);
    }
    return $the_content;
}
add_filter('the_content', 'replace_hello');
 
3. What is the $wpdb variable in WordPress, and how can you use it to improve the following code?
<?php
function perform_database_action(){
    mysql_query(“INSERT into table_name (col1, col2, col3) VALUES ('$value1','$value2', '$value3');
}
 
$wpdb is a global variable that contains the WordPress database object. It can be used to perform custom database actions on the WordPress database. It provides the safest means for interacting with the WordPress database.
The code above doesn’t follow WordPress best practices which strongly discourages the use of anymysql_query call. WordPress provides easier and safer solutions through $wpdb.
The above code can be modified to be as follows:
<?php
function perform_database_action(){
    global $wpdb;
    $data= array('col1'=>$value1,'col2'=>$value2,'col3'=>$value3);
    $format = array('%s','%s','%s');
    $wpdb->insert('table_name', $data, $format);
}
add_custom_script();
function add_custom_script(){
    wp_enqueue_script( 
        'jquery-custom-script',
        plugin_dir_url( __FILE__ ).'js/jquery-custom-script.js'
    );
}
 
wp_enqueue_script is usually used to inject javascript files in HTML.
The script we are trying to queue will not be added, because “add_custom_script()” is called with no hooks. To make this work properly we must use the wp_enqueue_scripts hook. Some other hooks will also work such as initwp_print_scripts, and wp_head.
Furthermore, since the script seems to be dependent on jQuery, it’s recommended to declare it as such by adding array(‘jquery’) as the 3rd parameter.

Proper use:

add_action(‘wp_enqueue_scripts’, ‘add_custom_script’);
function add_custom_script(){
    wp_enqueue_script( 
        'jquery-custom-script',
        plugin_dir_url( __FILE__ ).'js/jquery-custom-script.js',
        array( 'jquery')
    );
}
 
5. Assuming we have a file named “wp-content/plugins/hello-world.php” with the following content. What is this missing to be called a plugin and run properly?
<?php
add_filter('the_content', 'hello_world');
function hello_world($content){
    return $content . "<h1> Hello World </h1>";
}
 
The file is missing the plugin headers. Every plugin should include at least the plugin name in the header with the following syntax:
<?php
/*
Plugin Name: My hello world plugin
*/
 
6. What is a potential problem in the following snippet of code from a WordPress theme file named “footer.php”?
...
        </section><!—end of body section- ->
        <footer>All rights reserved</footer>
    </body>
</html>
 
All footer files must call the <?php wp_footer() ?> function, ideally right before the</body>tag. This will insert references to all scripts and stylesheets that have been added by plugins, themes, and WordPress itself to the footer.
 
7. What is this code for? How can the end user use it?
function new_shortcode($atts, $content = null) {
    extract(shortcode_atts(array(
        “type” => “warning”
    ), $atts));
    return '
‘.$content.’
';
}
add_shortcode(“warning_box”, “new_shortcode”);
This shortcode allows authors to show an info box in posts or pages where the shortcode itself is added. The HTML code generated is a div with a class name “alert” plus an extra class name by default, “alert-warning”. A parameter can change this second class to change the visual aspect of the alert box.
Those class naming structures are compatible with Bootstrap.
To use this shortcode, the user has to insert the following code within the body of a post or a page:
[warning_box]Warning message[/warning_box]
 
8. Is WordPress safe from brute force login attempts? If not, how can you prevent such an attack vector?
No, WordPress on its own is vulnerable to brute force login attempts.
Some good examples of actions performed to protect a WordPress installation against brute force are:
  • Do not use the “admin” username, and use strong passwords.
  • Password protect “wp-login.php”.
  • Set up some server-side protections (IP-based restrictions, firewall, Apache/Nginx modules, etc.)
  • Install a plugin to add a captcha, or limit login attempts.
 
9. The following line is in a function inside a theme’s “function.php” file. What is wrong with this line of code?
wp_enqueue_script('custom-script', '/js/functions.js');
Assuming that “functions.js” file is in the theme’s “js/” folder, we should use‘get_template_directory_uri()’. '/js/functions.js' or the visitors’ browser will look for the file in the root directory of the website.
 
10. Suppose you have a non-WordPress PHP website with a WordPress instance in the “/blog/” folder. How can you show a list of the last 3 posts in your non-WordPress pages?
One obvious way is to download, parse, and cache the blog’s RSS feeds. However, since the blog and the website are on the same server, you can use all the WordPress power, even outside it.
The first thing to do is to include the “wp-load.php” file. After which you will be able to perform any WP_Query and use any WordPress function such as get_posts,wp_get_recent_posts,query_posts, and so on.
<?php
    require_once('../blog/wp-load.php');
?>
<h2>Recent Posts</h2>
<ul>
<?php
    $recent_posts = wp_get_recent_posts(array(‘numberposts’=>3));
    foreach($recent_posts as $recent){
        echo '<li><a href="' . get_permalink($recent["ID"]) . '">' . $recent["post_title"] . '</a></li> ';
    }
?>
</ul>

Source: Toptal

Tuesday, August 30, 2016

Video Streaming Solution Tech Lead - Job Opening @Stockholm, Sweden - Kapil Sharma

                                                                                                                             
Tech Lead - Job @Stockholm

We are looking to strengthen our team with a Tech Lead/ Development Lead

We offer an exciting opportunity to develop world leading video streaming solutions in a fast paced and rapidly growing company. You will have a strong possibility to significantly contribute to the company´s development and continuous growth.

We are seeking an experienced Tech Lead to our headquarters in central Stockholm. Your job will include systems design, software development and requirements engineering, as well as software testing and quality assurance.

We required that you have:
  • Very good skills in C/C++ and Python as a bonus
  • Strong Linux skills

Preferably you have:
  • 7+ years of relevant working experience as Tech Lead and preferably with a background as a
Software Architect
  • Master of Science in computer science and engineering or similar
  • Experience with any of the following: NoSQL, Cassandra, ElasticSearch, CoffeeScript, node.js
  • Experience in device driver and kernel development
  • Experience in multi-threaded programming
  • Worked as a sounding board to PO
  • Good understanding of agile software development practices
  • Experience from video streaming

Matts Henriksson
HR Academy AB
Gamla Brogatan 19, NB
SE-111 20 STOCKHOLM
Sweden
+46 8 4103 1071
+46 733 681 254