i3Factory World

Your Iphone, iPad & Android Application Factory

Browsing Posts in News

Brevetto _patent_iPhone_curve_display_schermo_curvo

Rumors comes from Bloomberg, one of the world’s leading providers of information on the financial markets, Apple is developing an iPhone with curved screen and new pressure sensors.
Bloomberg also reveals the patent filed by Apple Inc., which makes the point that it is developing new models of the iPhone that most likely will include larger screens with curved glass and advanced sensors can detect the different levels

new-iPhone_curve_display_schermo_curvoTwo models are scheduled for release in the second half of next year would be characterized by larger displays with the glass that curves down at the edges. Sensors capable of distinguishing touches heavy or light on the screen will be incorporated in subsequent models, always  part of Bloomberg rumors (source: http://www.bloomberg.com/news/2013-11-10/apple-said-developing-curved-iphone-screens-enhanced-sensors.html) .

Samsung_galaxi_curve_diplay_schermo-curvoWith these two new models, curved screens of 4.7 inches and 5.5 inches, Apple is expected to approach the size of 5.7-inch Galaxy 3 Not3 that Samsung Electronics Co. launched last September. The South Korean manufacturer last month has launched a Galaxy with curved screen, the latest mobile phone in a variety of sizes and price ranges that Samsung is helping to keep ahead of Apple’s global market share in the sale of mobile phones.

The new smartphone from Apple are still in development and production plans have not been completed, said the source Bloomberg adding that the company would probably drop them going in the third quarter of 2014.

Apple then broke up with her glorious past in the month of September, when he presented two versions of the iPhone iPhone 5s with more advanced features and l ‘iPhone 5c colorful and somewhat lower prices, as part of a strategy that would see her compete on larger markets.

The first iPhone, released in 2007, offered a very functional and innovative touchscreen technology. Apple continues with its history of experimentation and the development of new materials in collaboration with the best suppliers of new technologies that will be able to improve the functions of your device.


Also according to Bloomberg said that Apple would open a new plant in Arizona to make components for its devices.

In conclusion

The fact that Apple could announce two new and different devices no longer so surprising, if we remember what he did with the iPhone and 5c 5s.
Therefore expect other sources that we confirm the introduction of pressure sensors, or rather of a screen that is capable of measuring the force applied on it, so darendere writing and drawing experience even more ‘innovative and fulfilling, and above all creative.

In an interesting article Matthew Panzarino asks, “’cause the look of the design iOS7 is so’ different from the previous” (Source: http://cdn.theapplelounge.com/wp-content/uploads/2013/06/iOS6vsiOS7_icons.png ).

After seeing the presentation of Apple iOS 7 now you know that the icons on the home screen (springboard cd) will change slightly.
Many of the new icons were designed mainly by members of the marketing and communications department at Apple, no more ‘by the development team of app. Jony Ive (now head of Human Interaction Apple) has guided step by step the design team to set the look and the color palette of the icons of the so-called stock app.



iOS7 Springboard


As has really changed the appearance of the icons of apps compared to iOS 6?
Let us see the comparison image created by @ pawsupforu:

Note that some icons have been taken directly from OS X (Safari), while others have been completely redesigned (Calendar)

ICONS DIMENSION , from 114px to 120px

iOS7 icone
IOS 7 Guide Freebie PSD

One of the major changes (over the design “flat”) is the change of size of the icons.
The application icons are now 120px iOS 7 (compared to the previous format of 114px) and the radius (Border Radius) is now 27px (20px compared to previous year). With this change comes the need to change the icon size of our app.
Fortunately, the designers Seevi Kargwal he designed the aforementioned iOS icon 7 in PSD format to help facilitate the process of redesign. You can check out more of the work.

Following the link to this web page http://dribbble.com/shots/1111211-IOS-7-Guide-Freebie-PSD you will find 2 ATTACHMENTS:
IOS_7_Guide_freebie_PSD.psd 900 KB
IOS-7-Guide-Full-Size.jpg 300 KB

iOS 7 Icon Rounded Corner Radius

The web site “Cult of Mac” argues that Jony Ive has given to the icons of iOS7 the same rounded corners iMac.

icone iOS7
icone Home – OS7 (Source)

Cult of Mac in his article argues that the new Director of Human Interface, Jony Ive, has redesigned iOS operating system as a multi-layered Parallax.
Ive qindi migrated its design philosophies and the hardware on iOS Messages app icon shows how you can get fecendo so that the corners of the icon messages have the same tapered edges that lie on the products Apple iMac.
The difference is only a small number of pixels that most users will probably never noticed, so Brad Ellis, who first discovered it, he created his own GIF comparison so you can actually see the changes:

Le icone di iOS7 hanno la stessa curvatura degli angoli dell'iMac
The icons of iOS7 have the same curvature of the corners of the iMac Brat Ellis.

In his blog Joel Page detailing the best corner of the icon as you can ‘see in the image below:


The new icon looks like a square with iOS7 dimesioni 120×120 px.

We conclude by considering the fact that the design changes with iOS 7 there sobno important innovations in the design of the icon.

The icons on the iPhone home screen received a slight increase in size to 114px by 57px and 60px and 120 px respectively.


We have introduced a new golden ratio grid and a new color scheme, much more ‘bright, that you will find included in the PSD file icon App Template This segiuendo link to this page:http://appicontemplate.com/ios7.
App icon Template , a Free Photoshop template is a resource that makes you more faciledisegnare icons. By changing a single object automatically returns you all the different formats required on iOS and Android.

Rivista della provincia di Milano
Rivista della provincia di Milano


Milano Province Magazine: La Provincia in Casa
has chosen to enter the mobile and tablet market with  i3Factory using the publishing system i3F Editorial, a technologically advanced solution without any cost management. The advanced technology of i3F Editorial allows publishers to publish new issues of the journal or magazine at no cost. It seems unbelievable but it is true.

The version for Apple iOS devices, all iPhone and iPod Touch (iPhone 3, iPhone5, iPhone 5) and iPad (iPad 3 Retina, iPad 4 Retina, iPad 1, iPad2) found at the following link:


The Android version for all smartphones and tablets Android (Samsung, Kindle, Sony, Asus, etc. ..):

https://play.google.com/store/apps/details?id=org.imaginor (GOOGLE PLAY- Android Market)

http://www.amazon.com/Provincia-Casa-Milano-italian-Magazine/dp/B00BUL9THS (Amazon App Store – Kindle fire)

i3Factory World  accompanies the Ministry of Labour through the i3Editorial Editorial System lands on the App Store.
An easy way to keep up to date on the world of work. Newsletter Cliclavoro is a monthly feature that collects the most important industry news, trends in the labor market, opportunities in Europe, interviews with personalities.

The newsletter is divided into 5 sections:

in opening
The interview
From Europe
From the Social Network

Keep up to date on market trends, with data and information enriched with links and multimedia content.
To follow in real-time news from the world of work CliComunica download the application.
Apple iPhone and iPad Version: https://itunes.apple.com/it/app/clicomunica/id582587332?mt=8

Android version: https://play.google.com/store/search?q=clicomunica&c=apps

iPhone5 has a larger screen than its predecessors. Developers iOS6 must support resolutions of 640 x 1136 px instead of 640 x 960 px pf iPhone4.
But even in this case if you follow the logic Apple work to be done is not at all complicated.

The blog   http://blog.mugunthkumar.com/coding/supporting-the-iphone-5/ proposes to follow four phases:

Phase 1:

iPhone 5 requires a new set of instructions, armv7s. Only in the last version of Xcode (4.5) supports the generation instruction set armv7s. Doa note that Xcode 4.5 no longer supports armv6 and deplores iPhone 3G and older devices. So we must now develop our application using Xcode 4.5

Phase 2:

The next step is to add a picture to launch (Default-568h@2x.png). When you build the project with Xcode 4.5, you receive a warning, “Missing 4 Retina launch image”. Click “Add” to add a default image to the project.


Step 3:

However, most of the nib file still will not be scaled correctly. The next step is to check the mask to automatically resize (auto resizing mask) of all the nib file and make sure that the view (view) in the nib file is automatically sized according to the new height of the view.


The properties that are used are:


It uses UIViewAutoresizingFlexibleHeight for display on top so that car size with the main window. It uses the UIViewAutoresizingFlexibleTopMargin and / or UIViewAutoresizingFlexibleBottomMargin for subviews.

UIViewAutoresizingFlexibleTopMargin is used if you want the subview eimanga “nailed” to the bottom (top edge is flexible) and UIViewAutoresizingFlexibleBottomMargin is used if you want the secondary display is “pinned” to the top (I bottom is flexible).

If you are using Cocoa Auto Layout, this step becomes optional. However, self Layout is not supported on iOS 5.


Finally, any Layer that you have added to the view must be manually resized. The following code shows how to do this. We use patternLayer to add a pattern for all view controllers. You need to resize the method viewWillLayoutSubviews.


-(void)viewWillLayoutSubviews {

self.patternLayer.frame = self.view.bounds;
[super viewWillLayoutSubviews];
}Step 5 (if you were a messy coder):


step 5

If the height of the view was encoded at 460 or 480, you may need to change all iinsrendo bounds. For example,


self.window = [[UIWindow alloc] initWithFrame: [[mainScreen UIScreen] bounds]];

instead of

self.window = [[UIWindow alloc] initWithFrame: CGRectMake (0, 0, 320, 480)];


Create images with the new dimensions

As I could see on the blog http://redth.info/get-your-monotouch-apps-ready-for-iphone-5-ios-6-today/ Unfortunately, the naming convention of image-568h @ 2x. png only seems to be used for the image by default, but does not apply to other images of ‘application. This means that if you are using a custom background image for display (eg UITableView background), you may need to create a new background image at the correct resolution, and the application to determine when to use each image.
It would be nice if Apple had extended into the new SDK support for the new screen using the method:
[UIImage imageNamed:@"my-image"]

Currently I can point to “my-image” the name of my image (without extension) and the operating system looks for the image in the application bundle according to this criterion: if the screen is an image with the search type retina @ 2x suffix in the name, if not found looks for the image without suffix. We would have expected from Apple to extend the algorithm to include the ability to search for the suffix-568h @ 2x in the case of screen sizes 4 “. Unfortunately it is not and that is why we encode it explicitly in our code.

For example, in our non-4inch compatible app, I have two images:

Images / TableViewBackground.png – 320×358
Images / TableViewBackground@2x.png – 640×716

With the new resolution, I need to create a third image (we decided to use the option-568h @ 2x.png naming convention, even if it is not processed by Apple):


An elegant approach is to create a new category for UIImage class (with a little imagination we call UIImage + Retina4), and perform at runtime within the category of a substitution method “imageNamed:” with one that can handle the new Convention:

// inside UIImage+Retina4.h

@interface UIImage (Retina4)


// all’interno di UIImage+Retina4.m
#import “UIImage+Retina4.h”

static Method origImageNamedMethod = nil;

@implementation UIImage (Retina4)

+ (void)initialize {
origImageNamedMethod = class_getClassMethod(self, @selector(imageNamed:));
class_getClassMethod(self, @selector(retina4ImageNamed:)));

+ (UIImage *)retina4ImageNamed:(NSString *)imageName {
NSMutableString *imageNameMutable = [imageName mutableCopy];
NSRange retinaAtSymbol = [imageName rangeOfString:@"@"];
if (retinaAtSymbol.location != NSNotFound) {
[imageNameMutable insertString:@"-568h" atIndex:retinaAtSymbol.location];
} else {
CGFloat screenHeight = [UIScreen mainScreen].bounds.size.height;
if ([UIScreen mainScreen].scale == 2.f && screenHeight == 568.0f) {
NSRange dot = [imageName rangeOfString:@"."];
if (dot.location != NSNotFound) {
[imageNameMutable insertString:@"-568h@2x" atIndex:dot.location];
} else {
[imageNameMutable appendString:@"-568h@2x"];
NSString *imagePath = [[NSBundle mainBundle] pathForResource:imageNameMutable ofType:@”png”];
if (imagePath) {
return [UIImage retina4ImageNamed:imageNameMutable];
} else {
return [UIImage retina4ImageNamed:imageName];
return nil;


What this code does is initializing replace Apple’s implementation of “imageNamed:” with our “retina4ImageNamed:” (and vice versa). At the very moment when the runtime calls “imageNamed:” actually going to call our function that will load the image optimized for the screen to 4 “on condition that it exists and that we are running the app on a device with this screen (including the simulator). If the image is not present or the screen is the traditional 3.5 “would then call the original function (renamed due to the initial exchange).
Obviously, this implementation can not be used in case the loading of images occurs explicitly by means of calls of the type
[UIImage imageWithContentsOfFile ...]
in which the name of the file to be constructed explicitly.

The Fugitive of the Space: Mission to Rome is an historical & fantasy movie adventure.


The first movie game live staged in the city of Rome.

Click here to Dowload from App Store
The Fugitive of the Space is the first movie game dedicated to the beauty of Rome city.
It’s a fun movie and interactive game. Dedicated to families or those who want to challenge themselves with this exciting adventure, including children and teenagers.

Entirely shot in the city of Rome, in Italy, this is a fun and educational experience.
You’ll discover the wonders of the eternal city while following the story and adventures of the main character, our Fugitive.

The History

The young Fugitive has just arrived on planet Earth and is walking around the beautiful city of Rome; near the Colosseum and the ancient wonders of the city.

He ran away from his planet, called NubiriX, using tele-transport . He escaped from his planet because he was betrothed to a rich and powerful princess of his kingdom.

Our friend has always been a romantic guy, and since the appearance of his bride who could not inspire him true love, he decides to run away to planet Earth and then following his instincts and his heart.

Unfortunately the ugly princess, after learning of the escape, has hired the royal guard master to chase his betrothed to bring him home. The captain of the guard, along with his crew, jumps into the hyperspace by following the traces of the tele-transportation that will take him in the solar system and finally on Earth.
The pursuers, however, have very reliable informations on our beloved planet and above all they manage to steal just a few images of the city of Rome.
The planet Nubirix is more than 2000 light years from earth and for this reason the images that appear on-board computer of the imperial guards are nothing but photographs of Rome 2000 years ago.

Will our Fugitive succeed in escaping from his pursuers and find, at last, true love on our planet Earth?

The fate of the Fugitive is now in your hands.

Dowload “Fugitive of the Space” from App Store



i3Factory has developed and published on behalf of ISNART and the Ministry of Agriculture and Forestry and Unioncamere, on the Apple App store and Android quieted interesting and useful application application:

10Q Ricette Italiane


Italian Recipes 10Q is an APP with more than 1000 Italian recipes chosen from the most representative at regional level and among the best known worldwide and represents a gastronomic journey that lets you know virtually Italy, through its flavors.

The aim is to present in detail the quality of products with a designation of origin (239 between PDO – PGI-STG), unique products that make a dish with the tradition, the work and dedication of the producers present only on some areas Italians.

The Italian restaurants in the world reported provide these dishes in their menu, constantly enriching this APP.

Consulting the “Recipes” gives easy access to ingredients that are needed, the method of preparation, the location of manufacture of ingredients (with clear maps geo-referenced) and tourist information to get in the territories.

Do not want to go shopping and want to use the ingredients you have at home (fridge / pantry)? Nothing more simple: put the ingredients on hand and the JPA will provide you with all the recipes that contain them, and can suggest some curiosity about the ingredients with a designation of origin. And if you are not satisfied with the success of your plate, you can always resort to the list of restaurants where you can taste the recipe you choose and your palate will be satisfied!

Bon appetit to all, wishing you could soon make a journey of taste in Italy, in search of those areas that make special local products!

And ‘an initiative of the Ministry of Agriculture and Forestry and Unioncamere

Below is the link to download the Italian Recipes 10Q.
Link for Android: https://play.google.com/store/apps/details?id=ricetteItaliane.Fragment&feature=search_result#?t=W10

Link for iOS (iPhone, iPod Touch e iPad): http://itunes.apple.com/us/app/10q-ricette-italiane/id510911650?mt=8

When you decide to design an app you must always follow the basic principles of industrial design.
Many people think of this commissioning an app, but when you are describing the application and then how their idea can be translated by the user experience and graphic interface (User Interface & User Experience), they are unprepared and very often they hide behind phrases like “I do not know this is a job for engineers, lets see this to the technicians …see ye.”

Needless to say,  when the  “technicians” get to work these people, who have no concept to delegate, will begin to demand substantive changes giving advice and information of any kind and almost always only after the app came to final stage of its development.
And the well-known concept that the “technical”, and engineers, first build the core of the application and then they adapt the design and  they do the opposite, in spite of themselves, only if the commitment are valid and convincing, especially when this is decided right from beginning of the design.
In accordance with the approach of “you do that then we see”, wanted by professionals distracted and ill prepared, the final aesthetic result can be poor which seem as every engineer knows that, before starting to write code, you need to have clear UI principles with a description of the functions related to the experience of the user.

Some sophists can criticize me for using the word “user”, which sometimes is not very appealing if you think that the end users are just people, or individuals users. This difference in meaning of words is very clear to me, but for ease of communication and especially for translation needs prefer to use the word “user” or “users” instead of ‘”individual”.


10 principles for a good design of an app and for a product

First of all, to quote Steve Jobs, I propose a definition of design that has convinced me more:
“Design is the fundamental soul of a man-made creation that ends up expressing itself in successive outer layers of the product or service.”

Of course, the same principles Jobs was inspired by Dieter Rams, former Braun’s designers, who enumerated his 10 principles for good design of a product:


Dieter Rams e i suoi prodotti di design


  • Dieter Rams Ten Principles of “Good Design”
    1. Good Design Is Innovative : The possibilities for innovation are not, by any means, exhausted. Technological development is always offering new opportunities for innovative design. But innovative design always develops in tandem with innovative technology, and can never be an end in itself.
    2. Good Design Makes a Product Useful : A product is bought to be used. It has to satisfy certain criteria, not only functional but also psychological and aesthetic. Good design emphasizes the usefulness of a product while disregarding anything that could possibly detract from it.
    3. Good Design Is Aesthetic : The aesthetic quality of a product is integral to its usefulness because products are used every day and have an effect on people and their well-being. Only well-executed objects can be beautiful.
    4. Good Design Makes A Product Understandable : It clarifies the product’s structure. Better still, it can make the product clearly express its function by making use of the user’s intuition. At best, it is self-explanatory.
    5. Good Design Is Unobtrusive : Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression.
    6. Good Design Is Honest : It does not make a product more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept
    7. Good Design Is Long-lasting : It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even in today’s throwaway society.
    8. Good Design Is Thorough Down to the Last Detail : Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.
    9. Good Design Is Environmentally Friendly : Design makes an important contribution to the preservation of the environment. It conserves resources and minimises physical and visual pollution throughout the lifecycle of the product.
    10. Good Design Is as Little Design as Possible : Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials. Back to purity, back to simplicity.


Of course it is easy to see that these principles will be adapted to the design of industrial products, but also for the design of applications, especially if they will be used on products that were built precisely according to the principles of good industrial design, as are all products Apple.

Design better, work less

Dieter Rams, creator of the 10 principles, has always expressed his approach to design with the phrase: “Weniger, aber besser” or “Less, but better.”
Minimalism, as well as being very elegant, is certainly the best way to allow all users-users to understand instinctively the product and its functionality and it makes the product itself, or the App, friendly to use (user friendly) and “pure”.

Heuristic evaluation

At this point I can only describe even the so-called heuristic evaluation.
The Heuristic Evaluation is a method of inspection that is performed exclusively by the experts of usability and allows to evaluate whether a set of general design principles have been applied correctly in the UI.
The guidelines (“Ten Usability Heuristics“) upon which this sort of evaluation were developed in 1990 by Jakob Nielsen and Rolf Molich and are designed for desktop software, but in this case, these principles are still valid for designed for touchscreen applications, such as the iPhone OS App for iPhone and iPad app for Android and Windows Mobile.


With the heuristic evaluation is detected then the fidelity and adherence to the principles of usability of the product, you can find on  Wikipedia ( http://en.wikipedia.org/wiki/Usability )

This method, which as we said, is a type of inspection, provides the only involvement of usability experts and does not call into question the end-users: for this reason it is easy to perform, cheap and fast but does not take into account the possible evolution of the needs of public and therefore, in my humble opinion, is certainly very useful but if it owns it in the limit of being inflexible, and the lack of flexibility can usually castrate the creative evolution.

The heuristic evaluation test , therefore consists in a series of navigation of the product which are carried out separately by each “expert”. During the test use, the software product is evaluated for both static aspects of the interface, such as window layouts, labels, buttons etc.., And for the dynamic aspects of interaction and (logical processes and flows).
After finishing the investigation, experts will gather in brainstorming, check the results and compare them with the principles provided in the guideline to reach some common conclusions.


The heuristic evaluation method is certainly very useful and often necessary, but it can also be done instinctively , if the “expert” who heads the app is an old business guru.

I doubt that when you follow these methods, very hard, is that you can easily fall in the risk assessments of caging in a bureaucratic system – with its sculpted rules – which severely limits the creative people, as suggested by the same creator iPhone and iPad, “think Different”.

Think Different is in fact always been the key to the success of each product in each sector.

Obviously none of the great success stories, “Think Different” model-based , has never ignored the existence of principles that Nielsen is one of the cultural foundations of this industry.
We must never ignore the basics, but even being locked in a few principles, how big and important they are, if you want to try to be innovative and revolutionary.

With this article I try to answer some questions.

  •      The company wants to develop its know-how?
  •      What is killing many companies that deal with development?


The problems of large IT companies are often sought in the development sector, so that the larger the company and more is looking to outsource their development. In some cases they try to control all the know-how internalising the functional areas at the expense of development.
That said I do not think remotely that there may be a problem in IT due to lack of skills of excellence within the company, rather they are convinced that the development industry is just what brain focuses more interesting, those who devoted to development is almost always a passion for deepening knowledge.
For this reason I see the problem of development focused on how developers are put together in the company, how they are managed and why they are made and what the criteria are entrusted roles.

In the experience I had been able to see the results of international excellence and quality only in brief moments, only determate “happy islands” that the market was ready to absorb. These development groups are evaporated by the time many of the companies I’ve known.

The assumptions behind the recruiting developers.

To explain this situation I’m going to make explicit some of the tacit assumptions that often underlie a large company of recruiting a team of business development. This is a crucial point because, in most organizations, those who influence these decisions in most cases will never be held accountable.

Based on the ideas of Ash Moran, the assumptions of the organization in this question appear to be the following:

  1. Developers are fungible
  2. The productivity is proportional to the duration of development
  3.  The requirements are all necessary

1. Developers are fungible

Tom de Marco, in his ” Slack:Getting Past Burnout, Busywork, and the Myth of Total Efficiency,” tell about “the myth of a fungible resource.”
Many jobs in the factory and warehouse are fully fungible in the sense that the time to bring someone up to full productivity is virtually irrelevant (hours or days). This is not true when it comes to software development, where even if a new hire knows the programming language, given the context, will take a long time to learn the basic code and business methods.

I do not think that developers are fungible (at least in most cases), but I have attended countless meetings in which decision makers were behaving as if this hypothesis is valid. Every time estimates in hand, the vast majority of managers acting as if a new developer can immediately increase the productivity of the team.
This assumption is in contradiction with what the developers think specifically about the nature of their work.

2. The productivity is proportional to the duration of development

There are two degenerative forms of thought to this hypothesis:

1) The idea that a developer who works 10 hours a day will be 25% more productive than one developer to work 8 hours a day

2) The belief that a team of 10 developers is 25% more productive than a team of 8.

I spoke of degeneration as we are convinced, like Ash, that the nature of software development is the creation of new knowledge, a concept that I described in a previous article.
We must think of dvelopers figures as they face a creative task. A job that involves constantly programmer, called increasingly to make logical decisions.

The hypothesis-productive-time is based on the idea that productivity can be represented as a linear scale at right angles. This is not true in the development, for the simple reason that the complexity in managing a team is not necessarily related to the number of people involved, but the nature of involvement and communication is needed to accomplish a given task.
Just think that sometimes is easier to play a role in many people, rather than trying to put 4 people agree on the choice of which movie to go see after dinner.
Obviously depends on the job, as well as some major IT projects you can do better with a small team.

Inattention is the main cause of major bugs.

Let me point out an interesting article: Do You Suffer From Decision Fatigue? ; il cervello umano ha una capacità limitata di fare scelte, e una volta stanchi, ci trova spesso a ricercare scorciatoie.

3. The requirements are all necessary

In most large software companies, functional requirements are defined outside of the development team. Unless the development team is not writing software only for himself, the so-called “Functional Area” (Functionals) will be involved in drafting a document that describes the work to be done by the development industry. Then sometimes it happens that 30% of the functionality in the software will never be used or not needed, then at least 30% of development time becomes pure waste. However, many teams are contractually obliged to provide a specification (document functional) without reference to the value of the specific characteristics of the same, this can be a source of bugs hard to heal.

4. The engaged team

When the development team is not operating at full capacity, it loses at least 25% of the time to rework and perform maintenance. If this happens the team does not produce high quality code, even though the skills of existing team are very high. Some bugs are introduced by developers who are tired and too stressed. The communication overhead reduces productivity in the short term
5. The team size
How many developers you should be taking?

The increased capacity is not the only reason why you should hire people. A very good argument is the redundancy. The teams are very small vulnerable to Murphy’s law, if your sole developer gets hit by a bus, the project will be in grave danger. But it is also possible that a team of 10 people and devastated by a single incident in the same bus. Some questions about the size of various work teams are detailed in an article by Christopher Allen entitled The Dunbar number as a limit to the size of groups.
A small teams may be less risky than it appears, because the developers are very rarely hit by bus, as is true though that must be managed as I very rarely leave their jobs for paymet reasons.
Programmers frequently leave the team due to poor working conditions, conditions that are almost always caused by the decisions of managers.

There is also a situation where you do want to increase the size of your team: when the person you are adding has the knowledge and experience to help improve the effectiveness of all others. In this case, however, their responsibilities must extend well beyond the pure development.


6. What to do?

The first thing is to step back and see if you are trying to solve a problem primarily caused by systematic futility in providing a greater effort to the team.
We know that if a Captain of a ship, which saw a flaw, order to all the sailors  to empty the water rather than monitor the situation and call a single engineer to repair the leak, would be ineffective.
Fred Brooks gave Brooks’s Law more than thirty years ago: “Adding manpower to a late software project makes it later.”
Improving the productivity of a team that develops software is difficult. It is about understanding the business, the team, the story and the obstacles that block progress. They are facing a complex problem, context-sensitive.
We see the world filtered through the metaphors that we can express.


Il costo di un’ App per iPhone & iPad

This is the italian translation of the article Dear business people, an iOS app actually takes a lot of work!, written by Kent Nguyen. Thanks Kent for giving us permission to publish this translated article.


Il grande quesito: quanto costa un’app per iPhone?

Questa è una domanda estremamente comune che viene sempre chiesta da un sacco di persone che lavorano nel mondo degli affari oppure da clienti non molto esperti di tecnologia. Senza dubbio, ogni volta che ho fornito una stima iniziale prima ancora di formalizzare e analizzare in dettaglio le specifiche, ho potuto vedere sui loro volti l’espressione di shock a causa della inaspettatamente alta quotazione.

Inoltre nessuna delle mie quotazioni si è lontanamente avvicinata ai valori discussi in, nel quale vengono discussi i costi di sviluppo dell’app Twitterific. Nonostante il fatto che la domanda originale fosse stata posta nel 2008 e la migliore risposta (da uno degli sviluppatori di Twitterific) fosse arrivata nel 2010, è ancora molto precisa all’inizio del 2012 ed è facile prevedere che lo sarà almeno fino alla fine dell’anno.

Cosí, con il crescere del numero di imprese che desiderano avere un’app per iOS, penso che sia una buona idea spiegare perché i costi siano effettivamente alti cercando di dividere i vari passi e spiegare le variabili coinvolte. Spero che questo articolo sia di beneficio per i non sviluppatori e gli uomini d’affari che devono prendere delle decisioni o semplicemente vogliono comprendere il processo. Le idee in questo articolo ovviamente non sono ristrette al solo mondo iOS ma possono essere estese ad altre piattaforme (Android, Windows Mobile, forse Blackberry).

Checklist: prepararsi ad un’app per iPhone

Il procedimento non è affatto semplice e cerco innanzitutto di informare il cliente a fare tutte le considerazioni guidandolo attraverso questi passi:

PRIMO: Una delle maggiori scoperte che ottengo parlando con i clienti è quanto siano inconsapevoli delle grande infrastruttura necessaria per un’app per iPhone. Dato che essi assumono che un’app sia semplicemente un’app, si aspettano che gli venga fornito il prezzo di fare qualunque cosa con l’app senza tener conto di problematiche quali: avere un server di supporto col quale l’iPhone comunichi, dove immagazzinare i dati dell’utente. La prima volta che incontrai un tale cliente ero furioso ma in seguito ho realizzato il fatto che il concetto di client-server non deve essere dato per scontato tra i non programmatori. Avevo sbagliato, i manager di solito non hanno il senso-tecnico comune che noi programmatori ci attendiamo.

Perciò, cari lettori non tecnici: è necessario che disponiate di un server nel quale memorizzare i dati per qualunque tipo di app che come minimo debba fare qualche autenticazione (login) o qualunque tipo di personalizzazione che volete cambiare in seugito o comunque qualunque operazione che richieda il recepimento di informazioni dall’utente (sto cercando di usare il linguaggio il più semplice possibile).

SECONDO: Dato che avete bisogno di un server, bisogna fare in modo che l’iPhone possa comunicare con tale server, inviando e ricevendo dati. Non esiste una maniera standard, non esiste nessun componente plug-and-play per fare questo, ogni cosa va customizzata. Questo è analogo a creare il vostro linguaggio personalizzato: non volete che gli altri comprendano ciò che state dicendo ma le due estremità, telefono e server, devono capirsi.

Questo processo consiste nella creazione di API (Application Programming Interface) per la vostra app. Queste API devono esistere prima che si proceda con lo sviluppo dell’app. Perché? perché prima di cominciare a comunicare occorre definire il linguaggio! Questo ci porta al prossimo passo, come creare queste API.

TERZO: Non prendere questo passo alla leggera, le API hanno un’importanza pari al 50% dell’intera soluzione. Fare un’API è come mettere in piedi un sito web. Prima devi definire i dati, quindi la logica di business, quali sono i parametri di ingresso a tale logica, come interagiscono fra loro i vari moduli quando accade un evento. Per semplificare, il risultato finale è un sito web completo dove però le pagine non mostrano risultati grafici ma solamente del testo che verrà compreso dalla nostra app: ad esempio una pagina di autenticazione conterrà, in caso di successo, la semplice parola YES.

L’iPhone quindi farà una serie di richieste a questi punti terminali predefiniti (pagina di login) usando il formato di ingresso predefinito dall’API (nome utente + password) e quindi interpreterà il risultato fornito da queste pagine in risposta alla sua richiesta (YES/NO). L’app senza questo non potrà mai registrarsi e fare il login magicamente da sola.

Ci sono *un sacco* di variabili che devono essere prese in considerazione in questa fase, come preparare un server, selezionare il linguaggio di programmazione con cui scrivere le API, dove immagazzinare i dati per minimizzare i tempi di comunicazione, ecc.

QUARTO: Queste API o sono già pronte e ben documentate dal vostro team interno per essere fornite allo sviluppatore iPhone oppure preparatevi a pagare di più che solo per la pura app. In funzione delle conoscenze dello sviluppatore che avrete contattato per farvi l’app, egli/ella potrebbe avere o meno le capacità per fare ciò di cui avete bisogno. Se lo sviluppatore è in grado di fare questo lavoro, allora vi consiglio fortemente di affidargli anche questa parte del progetto dato che egli sa esattamente quali API servono per far funzionare l’app al meglio.

Nel caso abbiate già le API dovrete dare allo sviluppatore la possibilità di parlare apertamente e liberamente con il vostro team di back-end e non limitarvi a dargli la documentazione; questo perché il più delle volte egli richiederà che venga fatto del lavoro in più (più API) per supportare l’applicazione mobile in maniera appropriata.

Adesso, la parte iPhone

Caspita, tutto questo per essere appena pronti a sviluppare l’app e non siamo ancora partiti! In generale, qualunque cosa riguardo iOS è molto restrittiva. Dovete quasi sempre aver definito circa il 100% dello scopo e del design prima che lo sviluppatore possa partire con la programmazione; diversamente dallo sviluppo di siti web, lo sviluppo di un’app per iOS sotto contratto ha pochissimi margini di cambiamento:

Disegnare l’interfaccia: La scelta se si devono utilizzare i componenti grafici standard o personalizzati deve essere presa già dall’inizio, dato che l’architettura dell’intera app dipende da come si vuole l’interfaccia e da come la utilizzeranno gli utenti.Un esempio è la Tab Bar in basso: se si vogliono i bottoncini colorati invece di quelli monocromatici standard, la modifica al codice è sostanziale!

Il codice è fortemente integrato: Con i siti web voi potete aggiungere semplicemente una pagina in più, quindi create un link a quella pagina ove richiesto. Non potete fare questo con un’app per iOS, dato che ogni cosa va decisa all’inizio e ogni cambiamento può risultare in cambiamenti significativi in altre parti dell’app. Il modo in cui il codice iOS è strutturato è come quello di una breadboard (le basette sperimentali per circuiti elettrici), dove ogni cosa è collegata con fili: voi potete sempre cambiare delle cose qui e là ma se tocchi il filo sbagliato allora l’intero circuito smetterà di funzionare. Anche se viene usato del codice estremamente ben strutturato la flessibilità non aumenterà molto. L’aggiunta di un bottone email addizionale nella schermata “About” potrebbe richiedere un ridotto numero di linee di codice addizionali, ma l’aggiunto di un bottone “Facebook Like” sulla stessa pagina è una cosa completamente differente e non ci può attendere che venga fatto in poche ore.

Convertire un’app per iPhone in un’app iPhone/iPad universale: Questa è la peggiore ‘funzionalità aggiuntiva’ presente nei contratti di sviluppo di app per iPhone. Questo perché un’app per iPad non è una banale funzionalità aggiuntiva. Le app per iPad sono di solito molto più complesse delle app per iPhone e il più delle volte sono richiesti un’interfaccia e un meccanismo di interazione completamente differenti. Non solo quello, dato che anche le API potrebbero essere diverse: l’app Denso, che ho sviluppato (e quindi conosco), ha alcune funzionalità esclusive dell’app per iPad che richiedono dati addizionali dal server. Inoltre l’iPhone e l’iPad richiedono esperienze utente differenti.

Dunque siete pronti a partire?

Spero che dopo aver letto questo abbiate un’idea più chiara di quel che è necessario alla vostra ditta per sviluppare un’app per il mondo mobile. A meno che non facciate un’app completamente offline (come una Calcolatrice!) che non raccoglie dati dagli utenti, non potrete pretendere che questa vi venga sviluppata a un prezzo basso. Dopo aver considerato le variabili elencate sopra, se non potrete giustificare lo sviluppo a contratto allora l’altra opzione è assumere a tempo determinato dei progettisti a tempo pieno che lavorino a tempo pieno per l’intera durata del progetto.

D’altro canto, se decidete di andare avanti e affidare in outsourcing il lavoro, c’e’ un’altra cosa da aggiungere: le lungaggini burocratiche. Se lavorate in una grande azienda o in un ambiente molto regolamentato, il vostro lavoro sarà essenzialmente di aiutare lo sviluppatore ad evitare le lungaggini burocratiche che potrebbe incontrare lungo la strada e talvolta avrete necessità di aggirare un pochino le regole. Ho parlato con molti clienti e ho potuto notare il loro scetticismo quando ho cercato di saperne di più sulle loro API, dato che essi o non desideravano esporsi maggiormente per non violare le loro regole di segretezza, e non potevo biasimarli, oppure non possono portare certi dati al di fuori del perimetro aziendale, oppure semplicemente (e questa è la cosa peggiore) le regole di branding aziendale richiedono che ogni singola pagina dell’app presenti il logo dell’azienda (!!!). Alla fine ho preferito non lavorare con questi clienti dato che non potevo immaginare quando a lungo avrei penato per ottenere anche un minimo supporto sulle API di cui avrei avuto bisogno.

P.S. Avrete bisogno di tempo, un sacco, per cui siate pazienti.