Fermer

juillet 30, 2019

Conception et construction d'une application Web progressive sans cadre (troisième partie)23 minutes de lecture


À propos de l'auteur

Ben Frain est un développeur, un auteur et un conférencier occasionnel. Un responsable technique UI / UX sur bet365.com, ses livres “Responsive Web Design with HTML5 and CSS3”…
Plus d'informations sur
Ben
Frain

Cet article conclut une série en trois parties sur les essais et les tribulations liés à la conception et à l'écriture d'une application Web de base avec JavaScript vanille. Dans la première partie, nous avons abordé le pourquoi, la deuxième partie principalement sur le comment et cette dernière partie se termine par l’analyse de la fin du projet et des leçons tirées de l’expérience acquise.

Dans la première partie de cette série, nous avons expliqué pourquoi ce projet était né. À savoir le désir d'apprendre comment une petite application Web pourrait être faite en JavaScript vanille et de faire un peu travailler un concepteur non-concepteur.

Dans la deuxième partie nous avons utilisé quelques conceptions initiales de base et fait fonctionner les choses avec quelques choix d’outils et de technologies. Nous avons expliqué comment et pourquoi certaines parties de la conception ont été modifiées et les conséquences de ces modifications.

Dans cette dernière partie, nous traiterons de la conversion d'une application Web de base en une application Web progressive (PWA) et de son envoi avant de regarder les leçons les plus précieuses tirées de la création d'une application Web simple In / Out:

  • L'énorme valeur des méthodes de matrice JavaScript;
  • Débogage;
  • Lorsque vous êtes le seul développeur, vous êtes l'autre développeur;
  • Le design est le développement ;
  • La maintenance en cours et les problèmes de sécurité;
  • Travailler sur des projets parallèles sans perdre la raison ni la motivation ni les deux;
  • L'expédition de certains produits est supérieure à celle de l'envoi d'un produit.

Avant d'examiner les leçons apprises, voyons comment transformer une application Web de base écrite en HTML, CSS et JavaScript en une application Web progressive (PWA).

En termes de temps total passé à la fabrication de cette petite application Web , J'inviterais c'était probablement autour de deux à trois semaines. Cependant, comme cela a été fait en morceaux de 30 à 60 minutes le soir, cela a pris environ un an à partir du premier engagement lorsque j'ai téléchargé ce que je considère être la version '1.0' en août 2018. Comme j'avais l'appli ' long métrage complet, ou plus simplement, à une étape qui me satisfait, j’anticipais un gros effort final. Vous voyez, je n'avais rien fait pour transformer l'application en une application Web progressive. Il s’avère que c’est la partie la plus facile du processus.

Création d’une application Web progressive

La bonne nouvelle est que, lorsqu’il s’agit de transformer une petite application JavaScript en une «application Web progressive», il existe des tas d'outils pour rendre la vie facile. Si vous vous reportez à la partie de la première partie de cette série, vous vous souviendrez qu'être une application Web progressive signifie satisfaire à un ensemble de critères .

En ce qui concerne les performances de votre application Web, vous devriez probablement commencer par utiliser les outils Lighthouse de Google Chrome. Vous pouvez trouver l'audit de l'application Web progressive dans l'onglet "Audits".

C'est ce que m'a dit Lighthouse lorsque j'ai parcouru In / Out pour la première fois.

 Les outils de développement de Chrome affichant les résultats de l'application Web progressive de 55/100.
Les scores initiaux pour Progressive Web App n'étaient pas géniaux. ( Grand aperçu )

Au début, In / Out obtenait seulement un score de 55 100 pour une application Web progressive. Cependant, je l'ai pris de là à 100 100 en moins d'une heure!

L'opportunité d'améliorer ce score n'avait rien à voir avec mes capacités. C'est simplement parce que Lighthouse m'a dit exactement ce qu'il fallait faire!

Quelques exemples d'étapes requises: inclure un fichier manifest.json (essentiellement un fichier JSON fournissant des métadonnées sur l'application), ajouter un fichier. Toute une série de balises méta dans la tête, remplacez les images insérées dans le CSS pour les images référencées par URL standard et ajoutez un tas d'images de l'écran d'accueil.

Créer un certain nombre d'images de l'écran d'accueil, créer un fichier manifeste et y ajouter un tas de balises méta peut sembler beaucoup à faire en moins d'une heure, mais il existe d'excellentes applications Web pour vous aider à créer des applications Web. Comme c'est gentil! J'ai utilisé https://app-manifest.firebaseapp.com . Donnez-lui des données sur votre application et votre logo, cliquez sur Soumettre pour obtenir un fichier zip contenant tout ce dont vous avez besoin! À partir de là, c’est juste le temps de copier-coller.

Des choses que j’avais retardées par manque de connaissances, comme un technicien, ont également été ajoutées assez facilement grâce à de nombreux blogs et sites dédiés à les travailleurs des services comme https://serviceworke.rs . Avec un technicien de service en place, cela signifiait que l'application pouvait fonctionner en mode hors connexion, une fonctionnalité indispensable d'une application Web progressive.

Bien que la création de l'application en PWA ne soit pas strictement liée à celle-ci, l'onglet "Couverture" des Outils de développement Chrome était également très utile. utile. Après tant d'itérations sporadiques sur la conception et le code au fil des mois, il était utile d'indiquer clairement où le code était redondant.

Très rapidement, après avoir étudié les recommandations de l'audit du phare, je me sentais comme l'animal de compagnie de l'enseignant:

 Obtenir un 100/100 sur le phare du Web progressif Vérification de l'application
Lighthouse facilite l'obtention de bons résultats en vous indiquant exactement ce qu'il faut changer. ( Grand aperçu )

En réalité, prendre l'application et la transformer en une application Web progressive était en fait incroyablement simple.

Cette dernière pièce de développement a conclu que j'ai transféré la petite application sur un sous-site.

Rétrospective

Plusieurs mois se sont écoulés depuis le développement de ma petite application Web.

Je l'ai utilisée avec désinvolture ces derniers mois. La réalité est que l’organisation du sport d’équipe est en grande partie transmise par SMS. Cependant, l’application est nettement plus facile que de noter qui va et vient que de trouver un bout de papier chaque nuit de jeu.

La vérité, c’est que ce n’est pas un service indispensable. Cela ne fixe pas non plus de barres pour le développement ou la conception. Je ne pourrais pas vous dire que je suis 100% heureux avec ça non plus. Je venais d'arriver à un point où j'étais heureux de l'abandonner.

Mais cela n'a jamais été le but de l'exercice. J'ai beaucoup profité de l'expérience. Ce qui suit est ce que je considère comme les points à retenir les plus importants.

Le design est le Le développement

Au début, je n’étais pas assez attaché au design. J'ai commencé ce projet en pensant que mon temps passé à dessiner avec un bloc-notes et un stylo ou dans l'application Sketch était un temps qui pourrait être mieux dépensé avec le codage. Cependant, lorsque je suis passé directement au code, j’étais souvent juste un imbécile occupé. L'exploration des concepts d'abord avec la plus faible fidélité possible a permis de gagner beaucoup plus de temps à long terme.

Au début, le début du travail passait de nombreuses heures à travailler quelque chose dans le code pour se rendre compte qu'il était fondamentalement défectueux du point de vue de l'utilisateur.

À mon avis, le papier et le crayon sont les meilleurs outils de planification, de conception et de codage. Tous les problèmes importants rencontrés ont été résolus principalement avec du papier et un crayon; l'éditeur de texte est simplement un moyen d'exécuter la solution. Si quelque chose n’a pas de sens sur le papier, cela n’a aucune chance de fonctionner en code.

La prochaine chose que j’ai appris à apprécier, et je ne sais pas pourquoi il a fallu si longtemps pour comprendre, c’est que le design est itératif. J’avais inconsciemment adhéré au mythe d’un designer avec un «D» majuscule. Quelqu'un voltige autour de lui, tenant son crayon mécanique en l'air, devenant lyrique au sujet des polices de caractères et sirotant un blanc éclatant (avec du lait de soja, évidemment) avant de donner au monde une perfection visuelle parfaitement formée.

du programmeur «génie», est un mythe. Si vous êtes nouveau dans la conception mais que vous essayez votre main, je vous suggère de ne pas vous accrocher à la première idée qui excite votre enthousiasme. C’est tellement bon marché d’essayer des variantes, alors profitez-en. Aucune des choses que j’aime dans la conception d’In / Out n’était présente dans les premières conceptions.

Je pense que c’est le romancier Michael Crichton qui a inventé la maxime: «Les livres ne sont pas écrits, ils sont réécrits». Acceptez le fait que chaque processus de création est essentiellement le même. Sachez que le fait de faire confiance au processus diminue l’anxiété et que la pratique affinera votre compréhension esthétique et votre jugement.

Vous êtes l’autre développeur de votre projet

Je ne suis pas sûr que cela soit propre aux projets sur lesquels on ne travaille que sporadiquement. mais j'ai formulé l'hypothèse imprudente suivante:

"Je n'ai pas besoin de documenter cela parce que c'est juste moi, et évidemment je vais le comprendre parce que je l'ai écrit."

Rien ne saurait être plus éloigné de la vérité!

Il y avait des soirées où, pendant les 30 minutes que je devais travailler sur le projet, je ne faisais rien de plus que d'essayer de comprendre une fonction que j'avais écrite il y a six mois. La principale raison pour laquelle la réorientation du code a pris si longtemps est le manque de commentaires de qualité, de variables et d'arguments de fonction mal nommés.

Je suis très diligent dans la façon de commenter le code dans mon travail quotidien, toujours consciencieux afin que quelqu'un d'autre ait besoin de comprendre. de ce que j'écris. Cependant, dans ce cas, j'étais ce quelqu'un d'autre. Pensez-vous vraiment que vous vous souviendrez du fonctionnement du bloc de code que vous avez écrit dans six mois? Vous ne le ferez pas Faites-moi confiance, prenez le temps de commenter cette chose!

Depuis, j’ai lu un billet de blog intitulé Votre surligneur de syntaxe est erroné au sujet de l’importance des commentaires. Le principe de base étant que les surligneurs de syntaxe ne doivent pas effacer les commentaires, ils doivent être la chose la plus importante. Je suis enclin à accepter et si je ne trouve pas bientôt un thème d'éditeur de code qui me gratte, je vais peut-être devoir l'adapter moi-même à cette fin!

Débogage

Lorsque vous rencontrez des bugs et que vous avez écrit tous les code, il n’est pas injuste de suggérer que l’erreur provient probablement du clavier et du fauteuil. Cependant, avant de supposer cela, je vous suggère de tester même vos hypothèses les plus fondamentales. Par exemple, je me souviens avoir pris plus de deux heures pour résoudre un problème que je supposais dû à mon code; sous iOS, je ne pouvais tout simplement pas que ma zone de saisie accepte la saisie de texte. Je ne me souviens pas pourquoi cela ne m’avait pas arrêté avant, mais je me souviens de ma frustration face au problème.

Il s’avère que cela était dû à un bogue de Safari, qui n’a toujours pas été corrigé. Il s'avère que dans Safari si vous avez:

 * {
  sélection de l'utilisateur: aucune;
}

Dans votre feuille de style, les zones de saisie ne prennent aucune saisie. Vous pouvez contourner ce problème avec:

 * {
  sélection de l'utilisateur: aucune;
}

entrée [type] {
  sélection de l'utilisateur: texte;
}

Quelle est l'approche que je prends dans ma réinitialisation CSS « App Reset ». Cependant, ce qui était vraiment frustrant, c’était que j’avais déjà appris cela et que je l’avais par la suite oublié. Lorsque j'ai finalement pu vérifier le suivi des bogues de WebKit tout en résolvant le problème, j'ai découvert que j'avais écrit une solution de contournement dans le fil de rapport de bogues plus qu'il y a un an avec réduction!

Les données? Apprendre les méthodes JavaScript Array

Peut-être que l'avancée la plus importante de mes compétences en JavaScript lors de cet exercice de création d'application a été de se familiariser avec les méthodes JavaScript Array. Je les utilise maintenant quotidiennement pour tous mes besoins en itération et en manipulation de données. Je ne saurais trop insister sur l'utilité de méthodes telles que map () filter () each () findIndex () find () et réduire () sont. Vous pouvez résoudre pratiquement tout problème de données avec eux. Si vous ne les avez pas déjà dans votre arsenal, mettez en signet https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array dès maintenant et creusez de suite comme vous pouvez. Mon propre récapitulatif de mes méthodes préférées de tableaux est documenté ici

ES6 a introduit d'autres épargnants de temps pour la manipulation de tableaux, tels que Set de reste . et Répandre . Faites-moi plaisir pendant que je partage un exemple; Il y avait un tas de faff si vous vouliez supprimer les doublons même d'un simple tableau plat. Plus maintenant.

Considérez cet exemple simple de tableau avec l'entrée dupliquée, «M. Pink»:

 let myArray = [
  "Mr Orange",
  "Mr Pink",
  "Mr Brown",
  "Mr White",
  "Mr Blue",
  "Mr Pink"
];

Pour supprimer les doublons avec ES6 JavaScript, vous pouvez maintenant faire:

 let deDuped = [...new Set(myArray)]; // Journaux détaillés ["Mr Orange", "Mr Pink", "Mr Brown", "Mr White", "Mr Blue"]

Ce qui nécessitait auparavant de lancer une solution à la main ou de rechercher une bibliothèque est désormais intégré dans le langage. Certes, sur des tableaux tels que court, cela peut sembler insignifiant, mais imaginez combien de temps cela vous fait économiser lorsque vous consultez des tableaux contenant des centaines d'entrées et de doublons.

Maintenance et sécurité

NPM, même s’il ne s’agit que de outils de construction, comporte la possibilité d’être vulnérable aux problèmes de sécurité. GitHub vous tient au courant des problèmes potentiels, mais il vous reste un fardeau d'entretien.

Pour quelque chose qui n'est qu'un projet parallèle, cela peut être un peu pénible dans les mois et les années qui suivent

En réalité, chaque fois que vous mettez à jour des dépendances pour résoudre un problème de sécurité, vous introduisez la possibilité de casser votre version.

Pendant des mois, mon package.json ressemblait à ceci: [19659072] {
  "dépendances": {
    "gulp": "^ 3.9.1",
    "postcss": "^ 6.0.22",
    "postcss-assets": "^ 5.0.0"
  },
  "name": "In Out",
  "version": "1.0.0",
  "description": "simple utilitaire pour voir qui est dedans et qui est dehors",
  "main": "index.js",
  "auteur": "Ben Frain",
  "licence": "MIT",
  "devDependencies": {
    "préfixe automatique": "^ 8.5.1",
    "synchronisation du navigateur": "^ 2.24.6",
    "cssnano": "^ 4.0.4",
    "del": "^ 3.0.0",
    "gulp-htmlmin": "^ 4.0.0",
    "gulp-postcss": "^ 7.0.1",
    "gulp-sourcemaps": "^ 2.6.4",
    "gulp-typescript": "^ 4.0.2",
    "gulp-uglify": "^ 3.0.1",
    "postcss-color-function": "^ 4.0.1",
    "postcss-import": "^ 11.1.0",
    "postcss-mixins": "^ 6.2.0",
    "postcss-nested": "^ 3.0.0",
    "postcss-simple-vars": "^ 4.1.0",
    "typescript": "^ 2.8.3"
  }
}

Et en juin 2019, GitHub m'avait donné ces avertissements:

 L'interface GitHub soulignant les problèmes de sécurité liés aux dépendances des outils de génération
Garder les dépendances répertoriées sur GitHub signifie des avertissements de sécurité peu fréquents. ( Grand aperçu )

Aucun n'était lié aux plugins que j'utilisais directement, ils étaient tous des sous-dépendances des outils de construction que j'avais utilisés. Telle est l'épée à double tranchant des paquets JavaScript. En ce qui concerne l'application elle-même, il n'y avait aucun problème avec In / Out; qui n’utilisait aucune des dépendances du projet. Mais comme le code était sur GitHub, j’ai eu le devoir d’essayer de régler le problème.

Il est possible de mettre à jour les paquets manuellement, avec quelques modifications de choix apportées à package.json. Cependant, Yarn et NPM ont leurs propres commandes de mise à jour. J'ai choisi de lancer yarn upgrade-interactive qui vous donne un moyen simple de mettre à jour les choses depuis le terminal.

 L'interface CLI permettant de mettre à niveau des paquets avec Yarn
Yarn rend la prédiction des dépendances de projet un peu plus précise. . ( Grand aperçu )

Cela semble assez facile, il y a même une petite touche colorée pour vous indiquer les mises à jour les plus importantes.

Vous pouvez ajouter le drapeau - le dernier pour mise à jour vers la toute dernière version majeure des dépendances, plutôt que simplement avec la dernière version corrigée. Pour un sou…

Le problème, c'est que les choses bougent rapidement dans le monde des paquets JavaScript. Il a donc été mis à jour quelques paquets avec la dernière version, puis une tentative de compilation:

 Erreur de génération Gulp
Erreur de génération Gulp ( Grand aperçu )

En tant que tel, j'ai annulé mon fichier package.json et essayé à nouveau sans le drapeau - le dernier . Cela a résolu mes problèmes de sécurité. Ce n’est pas très amusant j’ai eu un lundi soir bien que je sois honnête.

Cela touche une partie importante de tout projet parallèle. Etre réaliste par rapport à vos attentes.

Side Projects

Je ne sais pas si vous êtes pareil, mais j’ai constaté qu’un optimisme vertigineux et une excitation me poussent à démarrer des projets et, le cas échéant, à la gêne et à la culpabilité.

Ce serait un mensonge de dire que faire de cette application minuscule pendant mon temps libre était amusant. Il y avait des occasions où je souhaiterais ne jamais ouvrir la bouche à ce sujet. Mais maintenant, c’est fait, je suis à 100% convaincu que le temps investi en valait la peine.

Cela dit, il est possible d’atténuer la frustration suscitée par un tel projet parallèle en étant réalistes sur le temps qu'il faudra pour comprendre et résoudre les problèmes auxquels vous êtes confrontés. . Avez-vous seulement 30 minutes par nuit, quelques nuits par semaine? Vous pouvez toujours terminer un projet parallèle. Ne soyez pas mécontent si votre allure est glaciale. Si les choses ne peuvent pas profiter de toute votre attention, préparez-vous à un rythme plus lent et plus stable que celui auquel vous êtes peut-être habitué. C’est vrai, qu’il s’agisse de coder, de terminer un cours, d’apprendre à jongler ou à écrire une série d’articles expliquant pourquoi il a fallu tant de temps pour écrire une petite application Web!

Définition d’un objectif simple

Vous n’avez pas besoin d’un processus sophistiqué. pour l'établissement d'objectifs. Mais cela peut aider de diviser les choses en petites tâches / tâches courtes. Des choses aussi simples que «Ecrire CSS pour le menu déroulant» sont parfaitement réalisables dans un espace de temps limité. Considérant que "rechercher et mettre en œuvre un modèle de conception pour la gestion par l'Etat" ne l'est probablement pas. Briser les choses. Puis, comme dans Lego, les minuscules pièces vont de pair.

En pensant que ce processus élimine un problème plus vaste, je me souviens de la fameuse citation de Bill Gates:

«La plupart des gens surestiment ce qu’ils peuvent faire. un an et sous-estimez ce qu’ils peuvent faire en dix ans. »

Ceci provient d’un homme qui contribue à l’éradication de la poliomyélite . Bill connaît ses affaires. Écoutez Bill y'all.

Expédier quelque chose, c'est mieux que rien Rien

Avant d'expédier cette application Web, j'ai examiné le code et j'ai été complètement découragé.

Bien que je sois parti de ce voyage depuis un point de naïveté totale et d’inexpérience, j’avais fait des choix décents en ce qui concerne la manière dont je pourrais créer le code (si vous me pardonnez un terme aussi important). J’avais recherché et mis en œuvre un motif de conception et apprécié tout ce qu’il avait à offrir. Malheureusement, alors que je devenais de plus en plus désespéré pour conclure le projet, je n’ai pas réussi à maintenir la discipline. Le code dans sa forme actuelle est un véritable mélange d’approches et de nombreuses inefficacités.

Ces derniers mois, j’ai pris conscience que ces lacunes n’avaient aucune importance. Pas vraiment.

Je suis un fan de cette citation de Helmuth von Moltke.

"Aucun plan d'opérations ne s'étend de manière certaine au-delà du premier contact avec la principale force hostile".

Cela a été paraphrasé ainsi:

"Aucun plan ne survit au premier contact avec l'ennemi."

Peut-être pourrions-nous le résumer davantage et simplement nous contenter de "merde se passe"?

Je suppose que j'arrive à composer avec ce qui a été expédié via l'analogie suivante .

Si un ami annonçait qu’il allait tenter de courir son premier marathon, il n’aurait alors plus qu’à franchir la ligne d’arrivée – je ne les réprimanderais pas à l’heure d'arrivée.

s'est mis à écrire la meilleure application web . Mon mandat était simplement de concevoir et de créer un logiciel.

Plus précisément, du point de vue du développement, je souhaitais apprendre les principes de base de la construction d’une application Web. Du point de vue de la conception, je souhaitais essayer de résoudre certains problèmes de conception (bien que simples). Faire cette petite application a rencontré ces défis et plus encore. Le code JavaScript pour l’ensemble de l’application n’était que de 5 Ko (gzippé). Une petite taille de fichier que j'aurais du mal à obtenir avec n'importe quel framework. Sauf peut-être Svelte .

Si vous vous lancez un défi de cette nature et que vous vous attendez un jour à «expédier» quelque chose, écrivez dès le départ pourquoi vous le faites. Gardez ces raisons à l’avant-plan de votre esprit et laissez-vous guider. Tout est finalement une sorte de compromis. Ne laissez pas les nobles idéaux vous empêcher de terminer ce que vous aviez l'intention de faire.

Résumé

Globalement, dans la mesure où cela fait un an que j'ai travaillé sur In / Out, mes sentiments se divisent en trois grands domaines: choses que je regrettais, que j'aimerais améliorer / réparer et les possibilités futures.

Ce que j'ai regretté

Comme je l'ai déjà mentionné, j'étais déçu de ne pas m'être tenu à ce que je considérais comme une méthode plus élégante de changement d'état pour l'application et le rendre au DOM. Comme indiqué dans la deuxième partie de cette série, le modèle d'observateur, qui résolvait tant de problèmes de manière prévisible, a finalement été mis de côté car «expédier» le projet est devenu une priorité.

J'étais gêné par mon code au début, mais les mois suivants, je suis devenu plus philosophique. Si je n’avais pas utilisé plus de techniques piétonnières plus tard, il est fort probable que le projet n’aurait jamais abouti. Obtenir quelque chose dans le monde qui a besoin d’être amélioré est encore meilleur que jamais.

Improving In / Out

Au-delà du choix du balisage sémantique, je n’avais fait aucune concession en matière d’accessibilité. Lorsque j'ai créé In / Out, j'étais confiant avec l'accessibilité standard des pages Web, mais je ne connaissais pas suffisamment les connaissances pour traiter une application. J'ai effectué beaucoup plus de travaux / de recherches dans ce domaine maintenant, donc j'aimerais prendre le temps nécessaire pour rendre cette application plus accessible.

La mise en œuvre du nouveau concept de la fonctionnalité 'Ajouter une personne' a été mise en œuvre. précipité. Ce n’est pas un désastre, mais un peu plus brutal que je l’aimerais. Ce serait bien de rendre ce jeu plus glissant.

Je n'ai pas non plus pris en considération les écrans plus grands. Il serait intéressant d’envisager les problèmes de conception liés à l’utilisation de formats plus grands, au-delà de la simple transformation en un tube de contenu.

Possibilités

L’utilisation de localStorage a fonctionné pour mes besoins simplistes, mais il serait bien d’avoir un 'data store, il n’était donc pas nécessaire de s’inquiéter de la sauvegarde des données. L'ajout d'une capacité de connexion ouvrirait également la possibilité de partager l'organisation du jeu avec une autre personne. Ou peut-être que chaque joueur pourrait simplement marquer s'il joue lui-même? C’est incroyable le nombre de pistes à explorer que vous pouvez imaginer à partir de ces débuts simples et humbles.

SwiftUI pour le développement d’applications iOS intrigue également. À première vue, SwiftUI ressemble à quelque chose que je suis maintenant encouragé à essayer. J'essaierais probablement de reconstruire In / Out avec SwiftUI – juste pour avoir quelque chose de spécifique pour construire et comparer l'expérience et les résultats du développement.

Et donc, il est temps de conclure et de vous donner la version TL; DR de tout cela. .

Si vous voulez savoir comment quelque chose fonctionne sur le Web, je vous suggère de sauter les abstractions. Abandonnez les frameworks, qu’il s’agisse de CSS ou de JavaScript, jusqu’à ce que vous compreniez vraiment ce qu’ils sont pour vous.

Le design est itératif, adoptez ce processus

Résolvez les problèmes avec le support de fidélité le plus bas à votre disposition. N’utilisez pas de code si vous pouvez tester l’idée dans Sketch. Ne dessinez pas dans Sketch si vous pouvez utiliser un stylo et du papier. Écrivez la logique d'abord. Puis écrivez-le en code.

Soyez réaliste, mais ne vous découragez jamais. Si vous prenez l'habitude de réduire quelque 30 minutes par jour quelque chose, vous obtiendrez des résultats. Ce fait est vrai quelle que soit la forme de votre quête.

 Editorial Smashing (dm, il, ra)



Source link

Revenir vers le haut