Apr 212016
 

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.

The original article was written by KENT MUNDLE – TECHNICAL EDITOR @ TOPTAL and is found on the Toptal Design Blog.

Apr 212016
 

JavaScript: More than meets the eye

JavaScript can seem like a very easy language to learn at first. Perhaps it’s because of its flexible syntax. Or perhaps it’s because of its similarity to other well known languages like Java. Or perhaps it’s because it has so few data types in comparison to languages like Java, Ruby, or .NET.

But in truth, JavaScript is much less simplistic and more nuanced than most developers initially realize. Even for developers with more experience, some of JavaScript’s most salient features continue to be misunderstood and lead to confusion. One such feature is the way that data (property and variable) lookups are performed and the JavaScript performance ramifications to be aware of.

In JavaScript, data lookups are governed by two things: prototypal inheritance and scope chain. As a developer, clearly understanding these two mechanisms is essential, since doing so can improve the structure, and often the performance, of your code.

Property lookups through the prototype chain

When accessing a property in a prototype-based language like JavaScript, a dynamic lookup takes places that involves different layers within the object’s prototypal tree.

In JavaScript, every function is an object. When a function is invoked with the new operator, a new object is created. For example:

function Person(firstName, lastName) {
  this.firstName = firstName;
  this.lastName = lastName;
}

var p1 = new Person('John', 'Doe');
var p2 = new Person('Robert', 'Doe');

In the above example, p1 and p2 are two different objects, each created using the Person function as a constructor. They are independent instances of Person, as demonstrated by this code snippet:

console.log(p1 instanceof Person); // prints 'true'
console.log(p2 instanceof Person); // prints 'true'
console.log(p1 === p2);            // prints 'false'

Since JavaScript functions are objects, they can have properties. A particularly important property that each function has is called prototype.

prototype, which is itself an object, inherits from its parent’s prototype, which inherits from its parent’s prototype, and and so on. This is often referred to as the prototype chain. Object.prototype, which is always at the end of the prototype chain (i.e., at the top of the prototypal inheritance tree), contains methods like toString(), hasProperty(), isPrototypeOf(), and so on.

The relationship between JavaScript prototype and the scope chain is important

Each function’s prototype can be extended to define its own custom methods and properties.

When you instantiate an object (by invoking the function using the new operator), it inherits all the properties in the prototype of that function. Keep in mind, though, that those instances will not have direct access to the prototype object but only to its properties. For example:

// Extending the Person prototype from our earlier example to
// also include a 'getFullName' method:
Person.prototype.getFullName = function() {
  return this.firstName + ' ' + this.lastName;
}

// Referencing the p1 object from our earlier example
console.log(p1.getFullName());            // prints 'John Doe'
// but p1 can’t directly access the 'prototype' object...
console.log(p1.prototype);                // prints 'undefined'
console.log(p1.prototype.getFullName());  // generates an error

There’s an important and somewhat subtle point here: Even if p1 was created before the getFullNamemethod was defined, it will still have access to it because its prototype is the Person prototype.

(It is worth noting that browsers also store a reference to the prototype of any object in a __proto__ property, but it’s really bad practice to directly access the prototype via the __proto__ property, since it’s not part of the standard ECMAScript Language Specification, so don’t do it!)

Since the p1 instance of the Person object doesn’t itself have direct access to the prototype object, if we want overwrite getFullName in p1, we would do so as follows:

// We reference p1.getFullName, *NOT* p1.prototype.getFullName,
// since p1.prototype does not exist:

p1.getFullName = function(){
  return 'I am anonymous';
}

Now p1 has its own getFullName property. But the p2 instance (created in our earlier example) does nothave any such property of its own. Therefore, invoking p1.getFullName() accesses the getFullName method of the p1 instance itself, while invoking p2.getFullName() goes up the prototype chain to the Personprototype object to resolve getFullName:

console.log(p1.getFullName()); // prints 'I am anonymous'
console.log(p2.getFullName()); // prints 'Robert Doe'

See how P1 and P2 relate to the Person prototype in this JavaScript prototype example.

Another important thing to be aware of is that it’s also possible to dynamically change an object’s prototype. For example:

function Parent() {
  this.someVar = 'someValue';
};

// extend Parent’s prototype to define a 'sayHello' method
Parent.prototype.sayHello = function(){
    console.log('Hello');
};

function Child(){
  // this makes sure that the parent's constructor is called and that
  // any state is initialized correctly. 
  Parent.call(this);
};

// extend Child's prototype to define an 'otherVar' property...
Child.prototype.otherVar = 'otherValue';

// ... but then set the Child's prototype to the Parent prototype
// (whose prototype doesn’t have any 'otherVar' property defined,
//  so the Child prototype no longer has ‘otherVar’ defined!)
Child.prototype = Object.create(Parent.prototype);

var child = new Child();
child.sayHello();            // prints 'Hello'
console.log(child.someVar);  // prints 'someValue'
console.log(child.otherVar); // prints 'undefined' 

When using prototypal inheritance, remember to define properties in the prototype after having either inherited from the parent class or specified an alternate prototype.

This diagram shows an example of the relationship between JavaScript prototypes in a prototype chain.

To summarize, property lookups through the JavaScript prototype chain work as follows:

  • If the object has a property with the given name, that value is returned. (The hasOwnProperty method can be used to check if an object has a particular named property.)
  • If the object does not have the named property, the object’s prototype is checked
  • Since the prototype is an object as well, if it does not contain the property either, its parent’s prototype is checked.
  • This process continues up the prototype chain until the property is found.
  • If Object.prototype is reached and it does not have the property either, the property is considered undefined.

Understanding how prototypal inheritance and property lookups work is important in general for developers but is also essential because of its (sometimes significant) JavaScript performance ramifications. As mentioned in the documentation for V8 (Google’s open source, high performance JavaScript engine), most JavaScript engines use a dictionary-like data structure to store object properties. Each property access therefore requires a dynamic look-up in that data structure to resolve the property. This approach makes accessing properties in JavaScript typically much slower than accessing instance variables in programming languages like Java and Smalltalk.

Variable lookups through the scope chain

Another lookup mechanism in JavaScript is based on scope.

To understand how this works, it’s necessary to introduce the concept of execution context.

In JavaScript, there are two types of execution contexts:

  • Global context, created when a JavaScript process is launched
  • Local context, created when a function is invoked

Execution contexts are organized into a stack. At the bottom of the stack, there is always the global context, that is unique for each JavaScript program. Each time a function is encountered, a new execution context is created and pushed onto the top of the stack. Once the function has finished executing, its context is popped off the stack.

Consider the following code:

// global context
var message = 'Hello World';

var sayHello = function(n){
  // local context 1 created and pushed onto context stack
  var i = 0;
  var innerSayHello = function() {
    // local context 2 created and pushed onto context stack
    console.log((i + 1) + ':  ' + message);
    // local context 2 popped off of context stack
  }
  for (i = 0; i < n; i++) {
    innerSayHello();
  }
  // local context 1 popped off of context stack
};

sayHello(3);
// Prints:
// 1:  Hello World
// 2:  Hello World
// 3:  Hello World

Within each execution context is a special object called a scope chain which is used to resolve variables. A scope chain is essentially a stack of currently accessible scopes, from the most immediate context to the global context. (To be a bit more precise, the object at the top of the stack is called an Activation Object which contains references to the local variables for the function being executed, the named function arguments, and two “special” objects: this and arguments.) For example:

The way the scope chain relates to the objects is outlined in this JavaScript example.

Note in the above diagram how this points to the window object by default and also how the global context contains examples of other objects such as console and location.

When attempting to resolve variables via the scope chain, the immediate context is first checked for a matching variable. If no match is found, the next context object in the scope chain is checked, and so on, until a match is found. If no match is found, a ReferenceError is thrown.

It is important to also note that a new scope is added to the scope chain when a try-catch block or a withblock is encountered. In either of these cases, a new object is created and placed at top of the scope chain:

function Person(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
};

function persist(person) {
  with (person) {
    // The 'person' object was pushed onto the scope chain when we
    // entered this "with" block, so we can simply reference
    // 'firstName' and 'lastName', rather than person.firstName and
    // person.lastName
    if (!firstName) {
      throw new Error('FirstName is mandatory');
    }
    if (!lastName) {
      throw new Error('LastName is mandatory');
    }
  }
  try {
    person.save();
  } catch(error) {
    // A new scope containing the 'error' object is accessible here
    console.log('Impossible to store ' + person + ', Reason: ' + error);
  }
}

var p1 = new Person('John', 'Doe');
persist(p1);

To fully understand how scope-based variable lookups occur, it is important to keep in mind that in JavaScript there are currently no block-level scopes. For example:

for (var i = 0; i < 10; i++) {
  /* ... */
}
// 'i' is still in scope!
console.log(i);  // prints '10'

In most other languages, the code above would lead to an error because the “life” (i.e., scope) of the variable i would be restricted to the for block. In JavaScript, though, this is not the case. Rather, i is added to the activation object at the top of the scope chain and it will stay there until that object is removed from the scope, which happens when the corresponding execution context is removed from the stack. This behavior is known as variable hoisting.

It is worth noting, though, that support for block-level scopes is making its way into JavaScript through the new let keyword. The let keyword is already available in JavaScript 1.7 and is slated to become an officially supported JavaScript keyword as of ECMAScript 6.

JavaScript Performance Ramifications

The way that property and variable lookups, using prototype chain and scope chain respectively, work in JavaScript is one of the language’s key features, yet it is one of the trickiest and most subtle to understand.

The lookup operations we’ve described in this example, whether based on the prototype chain or the scope chain, are repeated every time a property or variable is accessed. When this lookup occurs within loops or other intensive operations, it can have significant JavaScript performance ramifications, especially in light of the single-threaded nature of the language which prevents multiple operations from happening concurrently.

Consider the following example:

var start = new Date().getTime();
function Parent() { this.delta = 10; };

function ChildA(){};
ChildA.prototype = new Parent();
function ChildB(){}
ChildB.prototype = new ChildA();
function ChildC(){}
ChildC.prototype = new ChildB();
function ChildD(){};
ChildD.prototype = new ChildC();
function ChildE(){};
ChildE.prototype = new ChildD();

function nestedFn() {
  var child = new ChildE();
  var counter = 0;
  for(var i = 0; i < 1000; i++) {
    for(var j = 0; j < 1000; j++) {
      for(var k = 0; k < 1000; k++) {
        counter += child.delta;
      }
    }
  }
  console.log('Final result: ' + counter);
}

nestedFn();
var end = new Date().getTime();
var diff = end - start;
console.log('Total time: ' + diff + ' milliseconds');

In this example, we have a long inheritance tree and three nested loops. Inside the deepest loop, the counter variable is incremented with the value of delta. But delta is located almost at the top of the inheritance tree! This means that each time child.delta is accessed, the full tree needs to be navigated from bottom to top. This can have a really negative impact on performance.

Understanding this, we can easily improve performance of the above nestedFn function by using a local delta variable to cache the value in child.delta (and thereby avoid the need for repetitive traversal of the entire inheritance tree) as follows:

function nestedFn() {
  var child = new ChildE();
  var counter = 0;
  var delta = child.delta;  // cache child.delta value in current scope
  for(var i = 0; i < 1000; i++) {
    for(var j = 0; j < 1000; j++) {
      for(var k = 0; k < 1000; k++) {
        counter += delta;  // no inheritance tree traversal needed!
      }
    }
  }
  console.log('Final result: ' + counter);
}

nestedFn();
var end = new Date().getTime();
var diff = end - start;
console.log('Total time: ' + diff + ' milliseconds');

Of course, this particular technique is only viable in a scenario where it is known that the value of child.deltawon’t change while the for loops are executing; otherwise, the local copy would need to be updated with the current value.

OK, let’s run both versions of the nestedFn method and see if there is any appreciable performance difference between the two.

We’ll start by running the first example in a node.js REPL:

diego@alkadia:~$ node test.js 
Final result: 10000000000
Total time: 8270 milliseconds

So that takes about 8 seconds to run. That’s a long time.

Now let’s see what happens when we run the optimized version:

diego@alkadia:~$ node test2.js 
Final result: 10000000000
Total time: 1143 milliseconds

This time it took just one second. Much faster!

Note that use of local variables to avoid expensive lookups is a technique that can be applied both for property lookup (via the prototype chain) and for variable lookups (via the scope chain).

Moreover, this type of “caching” of values (i.e., in variables in the local scope) can also be beneficial when using some of the most common JavaScript libraries. Take jQuery, for example. jQuery supports the notion of “selectors”, which are basically a mechanism for retrieving one or more matching elements in the DOM. The ease with which one can specify selectors in jQuery can cause one to forget how costly (from a performance standpoint) each selector lookup can be. Accordingly, storing selector lookup results in a local variable can be extremely beneficial to performance. For example:

// this does the DOM search for $('.container') "n" times
for (var i = 0; i < n; i++) {
    $('.container').append(“Line “+i+”<br />”);
}

// this accomplishes the same thing...
// but only does the DOM search for $('.container') once,
// although it does still modify the DOM "n" times
var $container = $('.container');
for (var i = 0; i < n; i++) {
    $container.append("Line "+i+"<br />");
}

// or even better yet...
// this version only does the DOM search for $('.container') once
// AND only modifies the DOM once
var $html = '';
for (var i = 0; i < n; i++) {
    $html += 'Line ' + i + '<br />';
}
$('.container').append($html);

Especially on a web page with a large number of elements, the second approach in the code sample above can potentially result in significantly better performance than the first.

Wrap-up

Data lookup in JavaScript is quite different than it is in most other languages, and it is highly nuanced. It is therefore essential to fully and properly understand these concepts in order to truly master the language. Data lookup and other common JavaScript mistakes should be avoided whenever possible. This understanding is likely to yield cleaner, more robust code that achieves improved JavaScript performance.

The original article was written by DIEGO CASTORINA – SOFTWARE ENGINEER @ TOPTAL and can be read here.

If you’d like to find more resources on Toptal designers or hire a Toptal designer, check this out.

Apr 172016
 

Hi,

Many times I have observed in the market, software vendors come out with many-many numerous products to satisfy the business needs of driving BI from click analysis to static reporting and planing systems.

But to my observation of some products (compared to the oceans of products out now in the space of BI) each product is trying to cater needs of multiple business making the product generic and flexible enough to adapt to the different domains of the business where it can fit in.

But indeed there are times when in the business needs are as such, you really cant fit in any off the shelf product apart from custom developing certain BI platforms which are custom designed to cater the needs of the specific business. (and hence you may observe that recently certain BI products have adapted to container based systems where business can code their custom components to fit in the entire BI application as per requirements)

In this post I wanted to introduced to one of the similar case study where I encountered a similar situation where any off the shelf product wasn’t available to meets the requirements hence I came up with one of architecture to suit the same:

One of the companies I worked for wanted to view the SSRS reports, for custom business metrics but along with that, they wanted that in certain areas of the reports they wanted the functionality to input comments on the report charts or metrics, and additionally they wanted a fancy way to illustrate KPI indicators manually controlled by super users becuase their indicators were more qualitative than quantitative.

Hence less of talking I take you through a straight walk through of the application:

The user navigates to the application via URL and land at the following page:

CropperCapture[1]

In this applcation you can pay special attention to the “Edit” button in the upper right hand corner of the screen which controls the report view mode.

Once this button is turned in the ON position the following is presented to the user:

(Also note the button is slide switch button to make the application, mobile friendly)

CropperCapture[2]

Now if you notice the two images above, where one is read only mode and the other edit mode the difference is the rectangular black border frame in the report edit mode around the comments with has the functionality that if the user clicks inside the frame the following is presented to the user to enter his comments for the same.

CropperCapture[3]

The comments what user enters is then saved along with the combination of report parameters the report was run, so it appears next time to be read or edited.

Similarly the comments box can transformed (via Code) to accommodate the KPI selections as well

CropperCapture[4]

Thus resulting in the following KPI on the report with similar features of edit mode of comments

CropperCapture[6]

Now the above post was just a small introduction of a comprehensive project i recently worked upon, which by piece meal i will keep posting about its various components in the next coming posts.

And just to give you a small flavor as how its all achieved

The UI is made of ASP MVC 5, in which the SSRS report container is hosted via ASP.NET MVC Html Helpers for ReportViewer Control, and post this the SSRS text box actions are composed of Javascript code, calling javascript functions on the hosting application Using Javascript in SSRS (leading those comment and traffic light boxes, for user selection) and all orchestrated via SQL backend.

Hope it helps.

Apr 172016
 

Hi,

Recently stumbling upon the SSIS double hop issue and figuring out the issue (after a lot of head scratching). The solution was posted out as follows:

Loading and Running a Remote Package Programmatically (MSDN)

– What is Double Hop Authentication Issue with SSIS ?

This article can provide a great insight into what is above mentioned issue CONFIGURING SQL SERVER KERBEROS FOR DOUBLE-HOP AUTHENTICATION

And to put it in simple words,

If your call your SSIS package (From Computer A), which is located on (Computer B, SQL Server Box) and the SSIS package tries to connect to the SSAS Cubes (Computer C).

SSIS package is unable to pass-on the credentials (windows Authentication) which was passed on by Computer A -> Computer B ->X-> Computer C

Hence leading to you package failure all the time when executed from Computer A, But if you jump on the Computer B it will always succeed. (Confusing and Hard to detect)

image_1

– Solution

Now the idea with the following solution, is to install a windows service on the SQL Server box to kick off the package with the authoritative credentials to replicate on the box instantiation of the package with authority to make the authenticated connection to the various sub systems like shared network drives, SSAS cubes and others (which uses Windows Authentication).

Note: This entire article is geared if you don’t want to mess with your organisational Active Directory setting up SPN’s and figuring out its not giving you desired results

The solution attached along with this article is a windows service solution (with the windows installer as well) which starts ups the self hosted web service ASMX (configurable via App.Config) providing the function to which the package details can be passed on with naive security via GUID. And the function also provides the features to pass on SSIS parameters by list of Names, Values and Types.

This information is then transformed as SQL script with gets executed on the box to surpass the above problem. Currently the solution is geared towards SSIS Package Deployment Model, but it can be altered as desired.

Hope it helps

Remote SSIS Package Execution Windows Service Download

Apr 032016
 

As front-end developers, our job is, essentially, to turn designs into reality via code. Understanding, and being competent in, design is an important component of that. Unfortunately, truly understanding front-end design is easier said than done. Coding and aesthetic design require some pretty different skill sets. Because of that, some front-end devs aren’t as proficient in the design aspect as they should be, and as a result, their work suffers.

My goal is to give you some easy-to-follow rules and concepts, from one front-end dev to another, that will help you go from start to finish of a project without messing up what your designers worked so hard on (or possibly even allowing you to design your own projects with decent results).

Of course, these rules won’t take you from bad to magnificent in the time it takes to read one article, but if you apply them to your work, they should make a big difference.

Do Stuff In A Graphics Program

It’s truly rare that you complete a project, and go from start to finish while maintaining every single aesthetic mutation in the design files. And, unfortunately, designers aren’t always around to run to for a quick fix.

Therefore, there always comes a point in any front-end job where you end up having to make some aesthetic-related tweaks. Whether it’s making the checkmark that shows when you check the checkbox, or making a page layout that the PSD missed, front-enders often end up handling these seemingly minor tasks. Naturally, in a perfect world this wouldn’t be the case, but I have yet to find a perfect world, hence we need to be flexible.

A good front-end developer has to use professional graphics tools. Accept no substitute.

A good front-end developer has to use professional graphics tools. Accept no substitute.

For these situations, you should always use a graphics program for mockups. I don’t care which tool you choose: Photoshop, Illustrator, Fireworks, GIMP, whatever. Just don’t just attempt to design from your code. Spend a minute launching a real graphics program and figuring out how it should look, then go to the code and make it happen. You may not be an expert designer, but you’ll still end up with better results.

Match the Design, Don’t Try To Beat It

Your job is not to impress with how unique your checkmark is; your job is to match it to the rest of the design.

Those without a lot of design experience can easily be tempted to leave their mark on the project with seemingly minor details. Please leave that to the designers.

Developers have to match the original front-end design as closely as possible.

Developers have to match the original front-end design as closely as possible.

Instead of asking “Does my checkmark look amazing?” you should be asking, “How well does my checkmark match the design?”

Your focus should always be on working with the design, not on trying to outdo it.

Typography Makes All the Difference

You’d be surprised to know how much of the end look of a design is influenced by typography. You’d be just as surprised to learn how much time designers spend on it. This is not a “pick-it-and-go” endeavor, some serious time and effort goes into it.

If you end up in a situation where you actually have to choose typography, you should spend a decent amount of time doing so. Go online and research good font pairings. Spend a few hours trying those pairings and making sure you end up with the best typography for the project.

Is this font right for your project? When in doubt, consult a designer.

Is this font right for your project? When in doubt, consult a designer.

If you’re working with a design, then make sure you follow the designer’s typography choices. This doesn’t just mean choosing the font, either. Pay attention to the line spacing, letter spacing, and so on. Don’t overlook how important it is to match the typography of the design.

Also, make sure you use the right fonts in the correct spot. If the designer uses Georgia for headers only and Open Sans for body, then you shouldn’t be using Georgia for body and Open Sans for headers. Typography can make or break aesthetics easily. Spend enough time making sure you are matching your designer’s typography. It will be time well spent.

Front-end Design Doesn’t Tolerate Tunnel Vision

You’ll probably be making small parts of the overall design.

Tunnel vision is a common pitfall for front-end developers. Don’t focus on a single detail, always look at the big picture.

Tunnel vision is a common pitfall for front-end developers. Don’t focus on a single detail, always look at the big picture.

An example I’ve been going with is making the checkmark for a design that includes custom checkboxes, without showing them checked. It’s important to remember that the parts you are making are small parts of an overall design. Make your checks as important as a checkmark on a page should look, no more, no less. Don’t get tunnel vision about your one little part and make it something it shouldn’t be.

In fact, a good technique for doing this is to take a screenshot of the program so far, or of the design files, and design within it, in the context in which it will be used. That way, you really see how it affects other design elements on the page, and whether it fits its role properly.

Relationships And Hierarchy

Pay special attention to how the design works with hierarchy. How close are the titles to the body of text? How far are they from the text above them? How does the designer seem to be indicating which elements/titles/text bodies are related and which aren’t? They’ll commonly do these things by boxing related content together, using varying white space to indicate relationships, using similar or contrasting colors to indicate related/unrelated content, and so on.

A good front-end developer will respect design relationships and hierarchy. A great developer will understand them.

A good front-end developer will respect design relationships and hierarchy. A great developer will understand them.

It’s your job to make sure that you recognize the ways in which the design accomplishes relationships and hierarchy and to make sure those concepts are reflected in the end product (including for content that was not specifically designed, and/or dynamic content). This is another area (like typography) where it pays to take extra time to make sure you’re doing a good job.

Be Picky About Whitespace And Alignment

This is a great tip for improving your designs and/or better implementing the designs of others: If the design seems to be using spacings of 20 units, 40 units, etc., then make sure every spacing is a multiple of 20 units.

This is a really drop-dead simple way for someone with no eye for aesthetics to make a significant improvement quickly. Make sure your elements are aligned down to the pixel, and that the spacing around every edge of every element is as uniform as possible. Where you can’t do that (such as places where you need extra space to indicate hierarchy), make them exact multiples of the spacing you’re using elsewhere, for example two times your default to create some separation, three times to create more, and so on.

Do your best to understand how the designer used whitespace and follow those concepts in your front-end build.

Do your best to understand how the designer used whitespace and follow those concepts in your front-end build.

A lot of devs achieve this for specific content in the design files, but when it comes to adding/editing content, or implementing dynamic content, the spacing can go all over the place because they didn’t truly understand what they were implementing.

Do your best to understand how the designer used whitespace and follow those concepts in your build. And yes, spend time on this. Once you think your work is done, go back and measure the spacing to ensure you have aligned and uniformly spaced everything as much as possible, then try out the code with lots of varying content to make sure it’s flexible.

If You Don’t Know What You’re Doing, Do Less

I’m not one of those people that thinks every project should use minimalist design, but if you’re not confident in your design chops and you need to add something, then less is more.

Less is more. If your designer did a good job to begin with, you should refrain from injecting your own design ideas.

Less is more. If your designer did a good job to begin with, you should refrain from injecting your own design ideas.

The designer took care of the main stuff; you only need to do minor fillers. If you’re not very good at design, then a good bet is to do as minimal amount as you can to make that element work. That way, you’re injecting less of your own design into the designer’s work, and affecting it as little as possible.

Let the designer’s work take center stage and let your work take the back seat.

Time Makes Fools Of Us All

I’ll tell you a secret about designers: 90 percent (or more) of what they actually put down on paper, or a Photoshop canvas, isn’t that great.

They discard far more than you ever see. It often takes many revisions and fiddling with a design to get it to the point where they’d even let the guy in the next cubicle see their work, never mind the actual client. You usually don’t go from a blank canvas to good design in one step; there’s a bunch iterations in between. People rarely make good work until they understand that and allow for it in their process.

If you think the design can be improved upon, consult your designer. It’s possible they already tried a similar approach and decided against it.

If you think the design can be improved upon, consult your designer. It’s possible they already tried a similar approach and decided against it.

So how do you implement this? One important method is taking time between versions. Work until it looks like something you like then put it away. Give it a few hours (leaving it overnight is even better), then open it up again and take a look. You’ll be amazed at how different it looks with fresh eyes. You’ll quickly pick out areas for improvement. They’ll be so clear you’ll wonder how you possibly missed them in the first place.

In fact, one of the better designers I’ve known takes this idea a lot further. He would start by making three different designs. Then, he’d wait at least 24 hours, look at them again and throw them all out and start from scratch on a fourth. Next, he’d allow a day between each iteration as it got better and better. Only when he opened it up one morning, and was totally happy, or at least, as close as a designer ever gets to totally happy, would he send it to the client. This was the process he used for every design he made, and it served him very well.

I don’t expect you to take it that far, but it does highlight how helpful time without “eyes on the design” can be. It’s an integral part of the design process and can make improvements in leaps and bounds.

Pixels Matter

You should do everything in your power to match the original design in your finished program, down to the last pixel.

Front-end developers should try to match the original design down to the last pixel.

Front-end developers should try to match the original design down to the last pixel.

In some areas you can’t be perfect. For example, your control over letter-spacing might not be quite as precise as that of the designer’s, and a CSS shadow might not exactly match a Photoshop one, but you should still attempt to get as close as possible. For many aspects of the design, you really can get pixel-perfect precision. Doing so can make a big difference in the end result. A pixel off here and there doesn’t seem like much, but it adds up and affects the overall aesthetic much more than you’d think. So keep an eye on it.

There are a number of [tools] that help you compare original designs to end results, or you can just take screenshots and paste them into the design file to compare each element as closely as possible. Just lay the screenshot over the design and make it semi-transparent so that you can see the differences. Then you know how much adjustment you have to make to get it spot on.

Get Feedback

It’s hard to gain an “eye for design.” It’s even harder to do it on your own. You should seek the input of othersto really see how you can make improvements.

I am not suggesting you grab your neighbor and ask for advice, I mean you should consult real designers and let them critique your work and offer suggestions.

Let designers critique your work. Put their criticism to good use and don’t antagonize them.

Let designers critique your work. Put their criticism to good use and don’t antagonize them.

It takes some bravery to do so, but in the end it is one of the most powerful things you can do to improve the project in the short-term, and to improve your skill level in the long run.

Even if all you have to fine tune is a simple checkmark, there are plenty of people willing to help you. Whether it’s a designer friend, or an online forum, seek out qualified people and get their feedback.

Build a long-lasting, productive relationship with your designers. It’s vital for useful feedback, quality, and execution.

Build a long-lasting, productive relationship with your designers. It’s vital for useful feedback, quality, and execution.

It may sound time consuming, and may cause friction between you and your designers, but in the big scheme of things, it’s worth it. Good front-end developers rely on valuable input from designers, even when it’s not something they like to hear.

Therefore, it’s vital to build and maintain a constructive relationship with your designers. You’re all in the same boat, so to get the best possible results you have to collaborate and communicate every step of the way. The investment in building bonds with your designers is well worth it, as it will help everyone do a better job and execute everything on time.

Conclusion

To summarize, here is a short list of design tips for front-end developers:

  • Design in a graphics program. Don’t design from code, not even the small stuff.
  • Match the design. Be conscious of the original design and don’t try to improve it, just match it.
  • Typography is huge. The time you spend making sure it’s right should reflect its importance.
  • Avoid tunnel vision. Make sure your additions stand out only as much as they should. They’re not more important just because you designed them.
  • Relationships and hierarchy: Understand how they work in the design so that you can implement them properly.
  • Whitespace and alignment are important. Make them accurate to the pixel and make them evenly throughout anything you add.
  • If you’re not confident in your skills, then make your additions as minimally styled as you can.
  • Take time between revisions. Come back later to see your design work with fresh eyes.
  • Pixel-perfect implementation is important wherever possible.
  • Be brave. Seek out experienced designers to critique your work.

Not every front-end developer is going to be a fantastic designer, but every front-end dev should at least becompetent in terms of design.

You need to understand enough about design concepts to identify what’s going on, and to properly apply the design to your end product. Sometimes, you can get away with blind copying if you’ve got a thorough designer (and if you’re detail oriented enough to truly copy it pixel for pixel).

However, in order to make large projects shine across many variations of content, you need some understanding of what’s going through the designer’s head. You don’t merely need to see what the design looks like, you need to knowwhy it looks the way it does, and that way you can be mindful of technical and aesthetic limitations that will affect your job.

So, even as a front-end developer, part of your regular self-improvement should always include learning more about design.

The original article was written BY BRYAN GREZESZAK – FREELANCE SOFTWARE ENGINEER @ TOPTAL and can be read here.

If you’d like to hire Bryan or one of Toptal’s great designers, click here – https://www.toptal.com/designers/resources