The new power pages styling is really nice and easy to use but i have tried every option and I could not figure out how to change the font Colour of the label of a field on my form and the magic way to do this is using a custom CSS and F12.

So follow the below steps to achieve this:

1. Login to make.powerpages.com , Select your environment and then Select your site from Active sites and click Edit

2. In the left navigation -> Navigate to Styling.

3. You can customise your Theme by adding colours to the colour and modifying in the theme and everything gets reflected as you change the colours which is very nice and very handy as you can see how things looks like.

4. Now to add a custom CSS file , Click the 3 horizontal dots on your selected them and click Manage CSS.

5. Navigate down and click Upload Custom CSS.

6. Upload your custom CSS and then Click Edit Code this opens the file in Visual studio Code, you can edit your CSS file there easily and once you save and click Sync Configuration.

7. Now comes the tricky part where you will need to have the discovery yourself which is trying to figure out the class name that you need to override. So to do so you need to use the preview on your portal so you can browse and then click F12 which opens your developer tools.

8. Using the developer tools you can navigate to the html component using the Ctrl+Shift+C , in my example I was trying to change the colour of the field label on the form, so i have picked the class name which is field_label

9. In Visual studio code , edit the class field_label, save and sync configuration and your changes will be reflected automatically

I will add here some of the class names I have used:

Modify the field label style	.field_label {}
Modify styling of submit button	.btn_submit {}

References:

https://learn.microsoft.com/en-us/power-pages/getting-started/tutorial-add-custom-style?WT.mc_id=DX-MVP-5004221

https://learn.microsoft.com/en-us/power-pages/configure/manage-css?WT.mc_id=DX-MVP-5004221

https://learn.microsoft.com/en-us/power-apps/maker/portals/edit-css?WT.mc_id=DX-MVP-5004221

Découvrez Blunt : une collection de classes CSS pour créer un layout responsive rapidement.

Tailwind ou pas Tailwind ? Ce framework CSS, fondé sur la méthodologie atomique, divise les rangs des intégratrices et intégrateurs. Chaque camp y trouve des arguments souvent très tranchés : on aime pas du tout ou bien on adore, il reste peu de place pour le "ça dépend".

Au sein de notre agence web Alsacréations, spécialisée dans les domaines front-end et dans l'accessibilité, nous avons expérimenté Tailwind depuis un peu plus de deux années à présent. Cet article détaille les leçons que nous avons tirées de l'usage ce framework.

Quelques précisions concernant notre contexte d'agence : nous ne sommes pas une start-up, nous intégrons des maquettes fournies par le client ou designées en interne et validées par le client. Même s'il nous arrive d'appliquer un framework pour un client (Bootstrap, Tailwind), notre expérience de plusieurs (dizaines d')années en intégration nous interdit le design de nouvelles pages "à l'arrache" comme certains pourraient être tentés de le faire avec ce genre d'outils.

Le mois de juin 2020 marque notre première intégration pour un client réalisée à l'aide de Tailwind CSS, puis une demi-douzaine de projets ont suivi. Sans oublier quelques projets personnels ou secrets.

En novembre 2020 nous publions sur Alsacréations l'article "Tailwind CSS, découverte du framework original et innovant". Quelques mois plus tard paraissent nos Guidelines Tailwind CSS publiques.

Enfin, en mai 2021, nous publions une sorte de synthèse sur la question : "Quels framework et méthodologie CSS choisir ?".

Point de départ : quelles étaient les problématiques à résoudre ?

Aucun projet d'intégration ne se déroule à la perfection, surtout dans la durée, et même au sein d'une agence web qui se considère comme compétente en la matière.

Rien que du côté CSS, les écueils que peut traverser un projet sont nombreux :

1. Séparation entre le fond (HTML) et la forme (CSS) : chacun devrait pouvoir s'occuper de son job et rester indépendant de l'autre.
2. Duplications des sélecteurs CSS (difficile de trouver, renommer, déplacer, supprimer les sélecteurs)
3. Collisions de noms (difficile de trouver des noms cohérents au fur et à mesure que le projet grossit + risque de choisir un nom déjà existant et d'écraser une partie des styles)
4. Spécificité des sélecteurs (ajouter du poids pour écraser un sélecteur a un effet "boule de neige" pour la prochaine modification à opérer)
5. Cascade (les règles de cascade CSS ne favorisent pas la compréhension ou la maintenabilité)
6. Code mort (le code inutilisé s'accumule au fur et à mesure que le projet grossit)

Notre expérience nous a souvent permis d'atténuer ces problèmes. Et quand je parle d'expérience, j'y inclus les différentes méthodologies que nous avons pu adopter chez Alsacréations : OOCSS dans un premier temps, BEM (un peu) et enfin Tailwind CSS.

Que nous apporte Tailwind CSS ?

Nous avons pu constater au cours de ces deux années d'usage que les promesses faites par Tailwind sont parfaitement tenues.

Les points suivants comptent parmi les plus retenus et cités dans notre agence :

• Résout plusieurs problématiques principales de CSS (nommage, spécificité, code mort, duplication des sélecteurs).
• Les classes utilitaires (espaces, polices, couleurs) permettent de gérer très finement les styles et leurs variations. Elles sont une bénédiction.
• L'outil s'adaptate à différents contextes (responsive, survol/focus, dark mode, etc.).
• Pourvu d'un écosystème riche (tutoriels, bibliothèques de composants, plugins navigateurs, plugins IDE : VSCode Tailwind Intellisense, etc.)
• Impose le même environnement et méthodologie pour tout le monde.

Les inconvénients de Tailwind

Sans surprise, TailwindCSS n'est pas exempt de désagréments. Voici une petite énumération que nous avons pu étabir en interne :

• Lecture du code HTML rendue fouillie et complexe (admettons-le, ça pique les yeux !)
• Nécessite une rigueur (guidelines) pour ne pas écrire n'importe quoi et dans n'importe quel ordre. Dans Tailwind, nous respectons encore plus l'ordre des propriétés
• Besoin d'un pense-bête Tailwind, parce que... items-baseline backdrop-invert-0 md:row-start-5 sm:content-around leading-snug dark:tracking-wider 🤷‍♂️
• Impossible de trouver des éléments précis dans le code (modale, wrapper, navigation, etc.).
• Inadapté pour les layouts "complexes" (gabarits, grilles non régulières, flexbox, etc.).
• Inadapté pour pas mal de fonctionnalités (transitions, animations, filtres, transformations)
• Durée de vie d'un Framework (comparé à la durée de vie de CSS ou d'une méthodologie)

Pour finir sur ce sujet, un témoignage assez évocateur :

Tailwind peut avoir un impact non négligeable sur certaines performances de chargement lorsqu'il y a de nombreuses répétitions de blocs (exemple vécu sur un projet client dont le menu généré pesait 40 Ko à cause des seules classes Tailwind)

Alors on fait quoi en pratique ?

Nous ne sommes sans doute pas les seuls dans ce cas, mais au quotidien on adapte Tailwind à notre sauce interne :

• On ajoute des noms "sémantiques" aux composants (pour pouvoir les retrouver, les désigner)
• On réserve les classes utilitaires pour un usage répétitif (marges, padding, gouttières, couleurs, typo)
• On s'équipe de plugins pour s'en sortir (ex. Tailwind Intellisense)
• On a toujours un onglet de navigateur ouvert avec la Doc de Tailwind ou un pense-bête tel que celui de Flowbyte ou Umeshmk

Nous sommes parfaitement conscients que nous n'employons pas ce framework "comme il faudrait" mais plutôt d'une façon hybride, cumulée avec d'autres méthodologies dans lesquelles nous piochons des idées à appliquer.

Vers l'après-Tailwind ?

Nous nous trouvons actuellement dans une phase de transition où l'on s'est remis à tester de nouvelles méthodologies et approches.

En toute transparence, Tailwind CSS ne nous convient pas à 100%. Ou plutôt, cela dépend des types de projets : sur certains projets, il nous paraît naturel de l'employer tandis que sur d'autres typologies il devient contre-productif.

Il est tout à fait probable qu'aucune méthodologie ne nous convienne parfaitement pour l'ensemble de nos prestations d'intégration et seul l'avenir nous le dira.

En attendant, un nouveau challenger est entré en jeu et nous commençons à le tester en production : Cube CSS.

CubeCSS n'est pas un framework mais une méthodologie plus générale. Pour le moment, nous la trouvons très prometteuse, mais laissez-nous le temps de l'expérimenter et… de vous partager nos conclusions dans un prochain article !

Publié par Alsacreations.com

Les styles CSS doivent leur nom à la Cascade, qui est un bien joli et complexe algorithme tenant compte de nombreux paramètres tels que l'origine des styles, la spécificité des sélecteurs ainsi que leur ordre d'apparence.

La Cascade, c'est l'essence même de CSS. C'est ce qui fait son utilité, sa beauté… et c'est aussi le pire cauchemar des intégratrices et intégrateurs.

La Cascade, c'est ce qui fait que nos paragraphes arboreront une chatoyante couleur hotpink avec les déclarations suivantes :

<p class="kiwi">Coucou !</p>

p {color: tomato;}
p {color: hotpink;}

Mais quel est le problème au juste ?

Dans un monde idéal, l'intégration HTML / CSS est prise en compte en amont du projet, en se donnant les ressources adéquates et les compétences nécessaires. Ce n'est bien évidemment pas un domaine que l'on traite à la légère, après le budget alloué à la communication, au SEO, aux développements "lourds" etc. en se disant que "après tout ce n'est que du CSS, même pas un vrai langage".

Mais ça c'est dans un monde idéal.

Dans un vrai projet, on récupère du code produit par des anciens stagiaires disparus ou par des frameworks de version obsolète, on a totalement oublié de s'appuyer sur une convention de nommage, on intègre avec un onglet de Stackoverflow toujours ouvert dans un coin, et on peste contre le monde entier à tenter d'écraser des styles avec !important (voire des !veryimportant ah non ça c'était une blague).

Qui n'a jamais utilisé !important me jette la première <br> !

Le vrai projet, c'est celui où l'on passe toujours trop de temps à comprendre pourquoi nos paragraphes sont chocolate et pas hotpink dans ce cas là :

p {color: tomato;}
.kiwi {color: pink;}
div p:first-child {color: chocolate;}
p.kiwi {color: hotpink;}

Où les Cascade Layers entrent en jeu

Les spécifications CSS ont introduit une règle-at @layer permettant de redéfinir l'ordre et la priorité dans la cascade CSS à l'aide de "layers" (couches).

Le principe général est simple : l'ordre de déclaration des layers (Layers Order) est prioritaire sur la spécificité des sélecteurs.

Ainsi, dans l'exemple qui suit, les paragraphes prendront la couleur hotpink car leur couche est déclarée en dernier.

@layer reset {
  p {color: olive;}
  .kiwi {color: pink;}
  div p:first-child {color: chocolate;}
}
@layer base {
  p {color: hotpink;}
}

Déclarer des layers

Il existe plusieurs moyens de créer des couches de styles : la règle @layer avec styles associés, la même sans styles, ou l'import de fichiers de styles externes.

Règle @layer avec styles associés

On déclare la couche via @layer en lui donnant un nom (optionnel) et on y applique des règles CSS.

@layer reset {
  /* ici les règles CSS de la couche reset */
}
@layer base {
  /* ici les règles CSS de la couche base */
}

Règle @layer sans styles

On déclare la couche via @layer vide.

@layer reset;
@layer base;

Pour info, cet exemple est équivalent à cette syntaxe :

@layer reset, base;

Cette formulation, sans styles associés, n'a d'autre but que de déclarer un ordre précis dans les couches.

Import de styles externes

La notion de layer peut être associée à la règle @import :

@import url("reset.css") layer(reset);

En plus de l'import via @import, le W3C travaille sur une version importée avec l'élément <link>.

Concrètement cela représente un moyen très simple de pouvoir :

• Importer les styles d'un framework tel que Boostrap (au hasard) au sein de layers, donc avec une spécificité moindre
• Pouvoir redéfinir ses propres styles sans se soucier du poids des sélecteurs Boostrap ni même des !important… et si j'évoque ce framework en particulier, ce n'est pas tout à fait anodin (oui, il y a bien 1307 !important dans ce seul fichier CSS)

@import url("bootstrap.css") layer(framework);

En pratique

Le postulat de base est que chaque layer est prioritaire sur le layer déclaré avant lui. L'ordre est donc primordial.

Dans l'exemple qui suit, tous les paragraphes seront de couleur hotpink même s'ils disposent de la classe .kiwi car le layer base est déclaré après reset :

@layer reset {
  p.kiwi {color: tomato;}
}
@layer base {
  p {color: hotpink;}
}

Étendre des styles aux layers existants

Il est possible d'ajouter des styles à une couche existante, simplement en reprenant le nom du layer déjà créé :

@layer reset {
  p.kiwi {color: tomato;}
}
@layer base {
  p {color: hotpink;}
  h1 {color: olive;}
}
@layer reset {
  h1 {color: chocolate;}
}

Dans cet exemple, les styles sur h1 sont ajoutés à ceux déjà présents dans la couche reset.

Notez qu'étendre des layers ne modifie pas l'ordre originel (et donc l'application) des layers. En clair, ici la couleur des titres h1 sera olive car le layer base est déclaré après reset.

Une bonne pratique consiste à définir dans un premier temps l'ordre de toutes les couches en une règle raccourcie (ex. @layer reset, base;), puis d'étendre les styles de chacun des layers, ainsi il n'est pas possible de se tromper dans l'ordre d'application des couches.

Dans l'exemple suivant, je souhaite prioriser les styles de la couche base, je vais donc commencer par indiquer l'ordre à respecter.

Ici, malgré ma maladresse (j'ai étendu les styles base puis ceux de reset), ce sont bien les styles de base qui sont prioritaires et s'appliquent. Les paragraphes seront hotpink :

@layer reset, base;

@layer base {
  p {color: hotpink;}
}

@layer reset {
  p {color: olive;}
  .kiwi {color: tomato;}
}

Particularité des styles sans layer

Cela peut paraître curieux, mais les styles sans layer sont appliqués en priorité.

Ainsi, dans l'exemple qui suit les paragraphes seront de couleur hotpink :

p {color: hotpink;}

@layer reset {
  p {color: olive;}
  p.kiwi {color: tomato;}
}

Imbrication de layers

On peut imbriquer les Cascade Layers de cette manière :

@layer framework {
  @layer reset {

  }
}

Il est ensuite possible d'étendre les styles de ce layer en y faisant référence ainsi :

@layer framework.reset {
  /* j'étends les styles dans le layer reset dans framework */
  p { color: hotpink; }
}

Compatibilité et mot de la fin

Bonne nouvelle : CSS Cascade Layers est une spécification dont le support est relativement large. À l'heure où cet article est rédigé, seules les anciennes versions de Safari et Samsung Internet sont à la traîne (si on ne tient pas compte d'Internet Explorer bien sûr). Cela signifie que cette fonctionnalité peut très vite être utilisable en production.

Et vous, qu'en pensez-vous ? Êtes-vous aussi impatient que moi de pouvoir bénéficier de cette spécification afin d'assainir radicalement tous les anciens projets web que l'on maintient tant bien que mal ?

Publié par Alsacreations.com

Un Reset CSS c'est quoi ? Pour quoi ?

Les navigateurs web sont tenus d'appliquer des styles par défaut (User Agent Stylesheet) à chaque page HTML, sinon le document afficherait une page blanche (source : specifications CSS).

Chaque navigateur applique ses propres styles par défaut pouvant se révéler différents les uns des autres, sinon ce serait trop facile pour nous autres développeuses et développeurs !

Deux méthodes permettent de contourner ces différences d'affichages entre les navigateurs : le Reset CSS et le Normalize CSS.

Reset ou Normalize ?

Un "Reset CSS" (réinitialisation) est une technique qui consiste à repasser toutes les valeurs des propriétés CSS à leur état initial afin repartir de zéro et d'une base vierge avant d'appliquer nos propres styles.

Un "Normalize CSS" (harmonisation) consiste à appliquer des styles de base cohérents identiques sur chaque navigateur. Cette méthode corrige également les différences d'interprétation des spécifications et d'affichage sur l'ensemble des navigateurs et produit une base de travail suffisante (typographie, interlignages, marges, etc.)

Cela dépend bien évidemment de vos besoins, mais dans la plupart des projets il est suffisant d'appliquer une couche de Normalisation, car un Reset vous forcera à redéfinir toutes les propriétés une à une pour votre projet.

L'article (en anglais) Normalize CSS or CSS Reset?! de Elad Shechter résume bien cette dualité d'outils.

L'article (en anglais aussi) A tale of CSS Resets and Everything You Need to Know About Them. Revisited. de Margo Roi est extrêmement riche en informations sur l'évolution des techniques de Reset / Normalize, leur intérêt dans le détail et propose une liste très complète de l'ensemble des solutions existantes actuellement (Eric Meyer, Yahoo!, Normalize, Sanitize, Reboot, Remedy, etc.)

Comprendre et provoquer l'héritage des propriétés

Une propriété héritable est une propriété qui récupère automatiquement la valeur de son parent. C'est le cas par exemple des propriétés typographiques ou des listes (ex. font-size, color, list-style, etc.).

Une propriété non héritable adoptera par défaut la valeur initial telle que définie dans les Spécifications. Par exemple une bordure, une largeur de boîte ou une couleur de fond n'est pas transmise par héritage aux descendants. La majorité des propriétés CSS ne sont pas héritables.

Voici une liste des propriétés CSS héritables courantes :

• color
• cursor
• direction
• font-family
• font-size
• font-style
• font-variant
• font-weight
• font
• letter-spacing
• line-height
• list-style-image
• list-style-position
• list-style-type
• list-style
• text-align
• text-indent
• text-transform
• visibility
• white-space
• word-spacing

Il est possible de forcer l'héritage d'une propriété en lui appliquant la valeur inherit. Elle prendra alors la valeur de la propriété du parent (c'est à dire son ancêtre direct).

Il est également possible de contrôler l'héritage de toutes les propriétés grâce à la propriété raccourcie all afin d'appliquer la valeur indiquée sur toutes les propriétés (source : MDN : Héritage).

Cibler toutes les propriétés via all

La propriété all est un super-raccourci de toutes les propriétés appliquables à un élément, ce qui lui permet d'hériter ou de réinitialiser toutes les valeurs à la fois.

Les valeurs possibles sont inherit, initial, unset et revert.

Exemple :

.parent {
  display: grid;
  margin: 2rem;
  color: hotpink;
}
.enfant {
  all: inherit; 
}

Dans cet exemple, all cible toutes les propriétés de .enfant et inherit les rend héritables, donc cela est équivalent au code suivant (pour les propriétés concernées) :

.enfant {
  display: grid;
  margin: 2rem;
  color: hotpink;
}

Appliquer les valeurs par défaut via initial

La valeur initial appliquée à une propriété lui confère sa valeur par défaut telle que prévue par les Spécifications CSS.

Exemple :

.parent {
  display: grid;
  margin: 2rem;
  color: hotpink;
}
.enfant {
  all: initial; 
}

Cet exemple est équivalent au code suivant (pour les propriétés concernées) :

.enfant {
  display: inline;
  margin: 0;
  color: canvastext;
}

Ce résultat peut surprendre dans la mesure où l'on s'attend généralement à la valeur block pour la propriété display (surtout si l'enfant est un élément tel que <div> ou <p>) ou black pour la propriété color, or il n'en est rien.

Il faut comprendre que toutes les propriétés CSS ont une valeur initiale définie dans les Spécifications (exemple display vaut inline). Puis elle est parfois écrasée par le navigateur au cas par cas selon les éléments (exemple div {display: block})

Quelques exemples de valeurs initial surprenantes :

• display: initial; vaut inline
• max-width: initial; vaut none
• width: initial; vaut auto
• position: initial; vaut static
• cursor: initial; vaut auto
• appearance: initial; vaut none
• color: initial; vaut canvastext (valeur récente, adaptée aux modes utilisateur Dark et Light).

Réinitialiser ou hériter via unset

La valeur unset appliquée à une propriété lui confère la valeur du parent si la propriété peut être héritée ou la valeur initiale dans le cas contraire.

Exemple :

.parent {
  display: grid;
  margin: 2rem;
  color: hotpink;
}
.enfant {
  all: unset; 
}

Cet exemple est équivalent au code suivant (pour les propriétés concernées) :

.enfant {
  display: inline;
  margin: 0;
  color: hotpink;
}

Dans cet exemple, display et margin ne sont pas héritables donc leur valeur est calculée à initial, mais la couleur, héritable, est transmise.

Quelques exemples de valeurs unset :

• max-width: unset; : non héritable donc unset vaut initial qui vaut none
• width: unset; : non héritable donc unset vaut initial qui vaut auto
• position: unset; : non héritable donc unset vaut initial qui vaut static
• font-size: unset; : héritable donc récupère la valeur du parent
• color: unset; : héritable donc récupère la valeur du parent (ici hotpink)

Friendly reminder: if you don't need IE/Edge support (e.g. internal tools), you don't have to reset every CSS property individually.

button.lame {
padding: 0;
border: none;
outline: none;
font: inherit;
color: inherit;
background: none
}

button.cute {
all: unset
}

— Benjamin De Cock (@bdc) April 24, 2018

Récupérer la valeur du navigateur via revert

La valeur revert récupère la valeur appliquée par l'Agent Utilisateur.
S'il n'y en a pas, revert devient unset (qui lui-même vaut inherit ou initial selon le cas 🤯)

Exemple :

.parent {
  display: grid;
  margin: 2rem;
  color: hotpink;
}
.enfant {
  all: revert; 
}

Cet exemple est équivalent au code suivant (pour les propriétés concernées) :

.enfant {
  display: block;
  margin: 0;
  color: hotpink;
}

Dans cet exemple, display vaudra block puisque c'est la valeur attribuée par le navigateur sur l'élément <div>. Le navigateur n'applique pas de valeurs spécifiques au propriétés margin et color donc elles deviendront respectivement initial et inherit.

Quelques exemples de valeurs revert selon l'élément appliqué :

• div {display: revert} vaut block
• p {display: revert} vaut block
• ​span {display: revert} vaut inline
• td {display: revert} vaut table-cell
• input {display: revert} vaut inline-block

Ces valeurs conférées par les navigateurs (User Agent Stylesheet) présentent parfois quelques différences selon les moteurs de rendu.

• Chromium UA stylesheet : concerne Google Chrome et Opera
• Mozilla UA stylesheet : concerne Firefox
• WebKit UA stylesheet : Safari

Vers le Reset / Normalize parfait ?

L'ensemble des propriétés et valeurs décrites au sein de cet article (all, inherit, initial, unset et revert) offre une très large panoplie de possibilités de réinitialisation en CSS lorsque cela vous est nécessaire.

Un Reset CSS proche de la perfection ressemblerait à ces deux simples lignes :

* {
  all: unset;
  display: revert;
}

Ces deux lignes résument à elles seules les consignes suivantes :

• Toutes les propriétés appliquables à tous les éléments doivent être remises à zéro, sauf pour les propriétés héritables qui sont conservées, cela évite de devoir tout re-styler notamment pour les propriétés typographiques.
• Concernant la propriété display, nous souhaitons que la navigateur continue d'appliquer ses valeurs préférées (donc block, inline, etc. selon l'élément).

Si la perfection existait, nous serions en présence du Reset ultime. Mais dans la vraie vie il y a aussi des images, des vidéos, des iframes, des tableaux, des SVG, etc.

Voilà pourquoi je ne saurais que vous conseiller de vous intéresser au projet "The New CSS Reset" maintenu sur Github par l'excellent Ahmad Shadeed et qui apporte les quelques affinages nécessaires.

Et vous, quelle est votre position par rapport à ces problématiques d'héritages, de cascades et de reset CSS ?

Avez-vous des solutions à tout faire que vous nous recommanderiez ?

Publié par Alsacreations.com

Modern SharePoint gives us few options from a design perspective. That sounds horrible, right? Actually, I see it as a very positive thing. By taking the pixel-pushing out of the mix, we can get people to focus on CONTENT, which is the do or die part of any Intranet.

Over the years, I was able to do a LOT of business (as Sympraxis) making “SharePoint not look like SharePoint”. But that came at a cost on several levels:

• My clients had to pay me to implement a design, which often wasn’t well-suited to SharePoint in the first place. Anyone remember the agony of getting rounded corners on Web Parts in the old days with just CSS?
• We focused a lot on that design, and far less on the content which we’d pour into it. Oftentimes, after we finally got the pixels in the right place, the content wouldn’t even fit into the pages very well!

Modern SharePoint gives us a clean, responsive, open user experience (UI) which few people quibble with. Years ago, many people driving Web site development had come from the print world, so there was a lot of that paper-perfect thinking in the mix. These days – a statistical generation later – most people driving the projects have always worked in the Web. The scales have tipped.

If you look at the SharePoint look book, virtually every one of the designs you see can be accomplished with out of the box settings. That’s a lot of power.

In modern SharePoint, there are several “design surfaces” we can work with:

• Theme(s) – We can devise a theme base on the organization’s primary color palette which can be applied to the Intranet site. We can have multiple themes, but they can only impact the main color palette on the sites. See: SharePoint site theming | Microsoft Docs and Fluent UI Theme Designer (windows.net)
• Imagery – We can create one or more Organizational Assets libraries to contain organizational imagery. These libraries might contain logos, product images, paid stock images, etc., and are available to all Site Owners when they build their sites. See: Create an organization assets library – SharePoint in Microsoft 365 | Microsoft Docs
• Iconography – SharePoint gives us a set of icons we can use for things like Quick Links, but we can also use custom images. For consistency, and simplicity, the out of the box set usually suffices. See: Fluent UI – Styles – React – Fluent UI Icons (microsoft.com) (Scroll down to see the icon set.) The Flicon – Fluent UI Icon Search site makes it easier to search that icon set (maintained by fellow MVP Chris Kent [@theChrisKent]).
• Site Icons – If your department or working group has a logo, the site icon can be that logo. The Intranet itself can have a logo, too. These logos are best created as square images which look good reduced to a fairly small size. In other words, not a lot of fancy details. See: Change the look of your SharePoint site (microsoft.com)
• Page Layouts – This starts to get more into content, but page layouts can be preconfigured for specific types of content, to ensure consistency and familiarity. See: Page templates in SharePoint (microsoft.com)

Anything beyond these design options usually would require custom coding and frankly often isn’t worth the effort. Having a designer available to make suggestions doesn’t hurt, but sometimes they get frustrated by the lack of options! These aren’t old-fashioned Web sites which required us to create an HTML template and CSS in order to get rolling. We can create a site and start working on the content right away, shortening the path to success immensely.

Big news in the beginning of this week. No, I'm not back to school :) I recently accepted a new job as an internal SharePoin employee for a company which is not yet an enterprise, but not a startup either. It will be very different than all of my past experience at service providers and consultancy engagements, but I am excited as it's a very innovative organization and we met when it's just about time for some SharePoint(ing).

Now to the point... one of my first tasks is to create the organization's navigation structure for an Intranet portal. We will use Managed Navigation after an evaluation and demos of all the possible methods. I will do this on SharePoint Online for the example, but the method is the same for SharePoint 2013 as well.

The decision to use Managed Navigation is not the scope of this post, a very good comparison by Microsoft is published here, which evaluates performance, needs and in fact all pros and cons.

One of the main requirements is for the Current Navigation to become collapsible, imagine a Windows Explorer style...like the following example. Now, if you have users that will be switching from file shares to SharePoint, that type of navigation might come handy. I personally don't really like the fact that it does go very big when you expand a lot of nodes, but there's a solution for that.

If the SharePoint site structure becomes deeply nested e.g. Site Collection -> Site -> Site -> Site ... this will also be a pain to navigate in, and most users would most likely prefer the Search option (I got this feedback after conducting a few user interviews and demoing this type of navigation).



Let's review the options to achieve the closest functionality in the SharePoint Current Navigation.
We assume we'll only have one site collection, which is nowadays common for small to medium sized organizations. Especially if you go the SharePoint Online route.

Option 1: Tree View

The way to enable this is simply going to Site Settings -> Tree View -> Enable Tree View.

The Tree View looks like this in a site collection (left) and respectively in a site (right):

Pros:
- Not collapsible OOB for use in Current Navigation. Needs custom CSS and potentially JavaScript.