Multiplayer architectural design software - world's fastest architectural floor plans

Laiout

laiout

In this article, we're going to look at all the different ways to lay out and navigate between different features in your apps. Flutter Flutter's pretty awesome for building apps that work everywhere – phones, computers, you name it. And a big part of making these apps user-friendly is getting navigation right. This article won’t cover navigation between screens. Instead, we will cover options for how to design your UI to account for navigation in some common cases. So, let’s start by discussing some of the factors involved in making such a decision. : It is very important for your app’s design to be as intuitive as possible. User’s not being able to understand your app is a big reason behind uninstalls. Onboarding and tutorial screens help, but that extra effort can be focussed elsewhere if your user already knows their way around the app. Intuition A really simple way to make it easier for users to understand your app is by designing it in a way that’s consistent with the default apps that come with the operating system. Material components are a good way to build your app following Google’s design conventions. Similarly, Cupertino widgets are a great way to make your app look and feel like the built-in iOS apps. Having a custom design language to make your app consistent on all platforms is very tempting but may not always be the best solution. : Depending on your app, the layout you choose matters a lot when it comes to experience. If you have many screens in your app and you present the user with too many options, it can be overwhelming which results in confusion and eventually to them not using the app out of frustration. In the same way, offering users very few options up front, which results in them having to interact with nested choices, may lead to too many clicks or a lack of understanding, making your app feel either too cumbersome to use or too confusing. User experience : If you have multiple features in your app, you may want users to interact with specific ones more than others; maybe these are paid features or just features that you feel add more value to the user. In cases like these, it is important to decide how to lay out your app so that the relevant items capture the user’s attention. Feature priority Let’s take a look at a couple of options and discuss when they can be useful: Tab Bar Navigation This usually involves a number of tabs either on the bottom (common in iOS apps) or the top (more common in Android) of the screen that lets users switch between features easily. This pattern is best used when you have a small set of equally important features on the same screen that you want users to easily access. Bottom tab bar-based layouts are great for UX because the user’s thumb can easily reach the tabs. Design principles Tab-based navigation usually involves a series of icons as tabs that the user can interact with. Based on the number of tabs, icons may also be accompanied by a label. The tab bar has limited space and should only be used for a small number of features. Clutter in the tab bar leads to really bad UX. Icons in the tab bar should be properly spaced to avoid accidental clicks to neighbor items. The tab bar should clearly indicate what the currently active tab is. The tab bar should be static and not require users to scroll to see more options. If you have too many options, the tab bar is not the right layout for you. Example In this example, we will be using a Cupertino-style tab bar. You can refer to the official to know how to use the material tab bar. Flutter documentation class MyHomePage extends StatelessWidget {
  const MyHomePage({super.key});

  @override
  Widget build(BuildContext context) {
    return CupertinoTabScaffold(
      tabBar: CupertinoTabBar(items: const [
        BottomNavigationBarItem(
          icon: Icon(CupertinoIcons.home),
        ),
        BottomNavigationBarItem(
          icon: Icon(CupertinoIcons.settings),
        ),
      ]),
      tabBuilder: (builderContext, position) {
        return CupertinoTabView(
          builder: (tabViewContext) {
            return Center(
              child: Text('Tab $position'),
            );
          },
        );
      },
    );
  }
} This example would look like this: Carousels Carousels are horizontal scroll-based layouts where the user swipes to switch between views. These are often used for features such as onboarding, photo galleries, etc. Carousels can be full screen or a percentage height; typically each individual view of a carousel is full width, but you can have them be slightly smaller to make it evident that there is a next item that can be scrolled to. iOS typically has paged carousels, meaning you always fully scroll to the next item, even if the user only scrolls partially. Generally, if the user does only partially scroll to the next item, you should automatically scroll such that the item is fully in view. When you have a few items in the carousel (for example, in your onboarding flow), it is a good idea to also add an indicator with your carousel that informs users about how many items there are and has a way to show what position they are currently at. If you have many items (let’s say a photo gallery), including an indicator will just add clutter. In this case, it’s better to add some sort of action (arrows, for example) that lets users trigger a scroll to the next item and then disable that action visually to indicate that they have reached the end. Carousels are best used when you want to lay out more than 2-3 items (at least 3) horizontally. You should use a tab bar instead of a full-screen carousel if you have 2-3 items that are independent features. Design principles The default action to move between items should be user interaction (scroll or click) Be careful not to have conflicts with gestures on the same screen. For example, swiping your carousel should not accidentally trigger swiping between tabs. Infinite scrolling/paging is a good way to enhance the UX of your carousels. Carousels are best used for swiping between items that are similar and have the same context as the user. Using them for independent features should be avoided if possible because overuse of such carousels leads to confusion and makes navigation in your app less intuitive. Items in your carousel should not negatively affect the smoothness of the scroll/animation between items. Any computationally intensive or I/O operations should be made in a way where they don’t block the primary UI thread. If items in the carousel are loaded over network calls, appropriate placeholders should be used to avoid making the content appear blank as the user interacts with it. Example While you can create a carousel from scratch in Flutter, you can also use a library created by someone else to implement some of these design patterns. For example, at the time of writing, was one of the more popular libraries on for carousels in Flutter. carousel_slider pub.dev Segmented Control This pattern is something that is used mainly in iOS and other Apple frameworks. Segmented control involves separating your view into separate segments that the user can toggle between using some controls. This type of pattern is useful when you need to separate your layout, but the different segments all share the same context (for example, switching between missed and normal calls in the phone app). While this in Android, it may not be a good idea if the rest of the app follows the normal material guidelines because it would feel out of place. Flutter allows you to implement Common use cases of segment controls include filtering content, switching between different views for the same data (list and map views, for example), etc. Design principles Segment control should only be used for a small number of options, typically not more than 4. Because users can also swipe between the controls, it adds to the delight factor of using your app. The control is typically compact and allows for more real estate for the actual content of your app. The layout is very straightforward and is designed to be very intuitive. The labels for the controls should be very clear and single-worded so users can easily identify how to interact with them. The selected segment should be highlighted clearly. Example In this example, we use , but you can use if you want a more material look for your app. CupertinoSlidingSegmentedControl SegmentedButton class _MyHomePageState extends State<MyHomePage> {
  String selectedIndex = '1';

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: SafeArea(
        child: Center(
          child: Column(
            children: [
              CupertinoSlidingSegmentedControl(
                groupValue: selectedIndex,
                children: const {
                  "1": Text("First"),
                  "2": Text("Second"),
                },
                onValueChanged: (value) {
                  if (value != null) {
                    setState(() {
                      selectedIndex = value;
                    });
                  }
                },
              )
            ],
          ),
        ),
      ),
    );
  }
} This will render the following: Stories Stories is inspired by popular social media apps but have since become a popular design pattern. Stories are a popular way of showcasing content in a sequential and immersive way, useful for showing content such as tutorials, guides, product showcases, etc. Design principles Stories are designed for content to be displayed for small periods of time and to switch between stories when the time has elapsed. Users should be allowed to switch between stories by tapping or swiping. Stories are designed for visually engaging content, such as images or videos. Easy navigation between items is a . big boost to UX Because stories are usually full-screen, they are a good way to drive engagement to the content you want users to focus on. Because stories are a staple for social media apps, it helps increase the appeal of your app with younger audiences. Example At the time of writing this article, was one of the more popular libraries for adding stories like layout to Flutter apps. story_view There are plenty more options when it comes to design patterns for navigation UI; you can pick and choose or combine multiple ones to design really good-looking apps. The key to choosing between them is to maintain clarity and ease of use for your users while keeping the general usability of your app as intuitive as possible.

A Guide to UI Design Patterns in Flutter: Navigation and Layout

I've written a few posts lately about multi-host live streams with Amazon Interactive Video Service (Amazon IVS). It's an exciting feature that opens up worlds of possibilities that simply weren't available until recently. We first looked at how to . create a multi-host live chat application Next, we saw how to broadcast that live chat session to an Amazon IVS channel. When we looked at adding chat participants to the broadcast client in that last post, you probably noticed that I cheated a bit and hardcoded the values that tell the broadcast client the size and position of the participant's video on the client. VideoComposition Well - cheated is a strong word - let's say that I intentionally simplified the code to focus on the process of broadcasting a live chat session. Essentially what we're looking for here is modifying the size and position of the participant's video in the broadcast so that when there is one video, the layout will look something like this: But when there are two videos, the layout will change to something like this: And when there are five: You get the idea - a dynamic layout that changes based on the amount of participants. In this post, we'll take a look at one approach you could utilize to make creating a dynamic layout a bit easier. We'll build off of the solution in the last post, so if you haven't read that post yet, it's probably a good idea to do that now. In the last post, we listened for an event called . In the event handler for that event, we added our participants to the DOM and rendered the audio and video to the instance. STAGE_PARTICIPANT_STREAMS_ADDED IVSBroadcastClient In order to render a dynamic layout, we'll need to track how many participants are currently in the session, so we'll add an array called as a global variable. Let's modify the event handler to push the current participant id to that array. participantIds stage.on(StageEvents.STAGE_PARTICIPANT_STREAMS_ADDED, (participant, streams) => {

  //add participant id to array
  participantIds.push(participant.id);

  renderParticipant(participant, streams);
  renderVideosToClient(participant, streams.find(s => s.streamType === StreamType.VIDEO));
  renderAudioToClient(participant, streams.find(s => s.streamType === StreamType.AUDIO));
  updateVideoCompositions();
}); In the last post, I mentioned that the method was not shown because the implementation would vary. We'll talk about one possible implementation in just a bit. updateVideoCompositions() For now, let's take a look at how we can get a dynamic layout config instead of hardcoding it as we did in the last post. One way to obtain a dynamic size and position is to loop over the participant array and calculate them based on the number of participants, the size of the , and the desired amount of rows, columns, and padding. But, ? <canvas> why That sounds like a lot of difficult code and unnecessary work when you realize that these values never change. If you have one participant, the video will be a fixed size and centered in the . <canvas> It doesn't matter how many participants get added - the layout for each video will always be the same for a given number of participants. So why waste time and CPU cycles when we could pre-calculate these values and store them in an array of arrays? For my demo, I spent some time determining the best values with an intensive 30 minutes with a pen, paper, and calculator to determine the composition values for each possible layout. Please note: I was a maths or art major as evidenced by the following sketch. not For this demo, I capped my live stream at only showing videos for the first 6 participants. Your use case may dictate something different, but having more than 6 participant videos in one live stream becomes a bit too busy in my experience. Here is the result of my calculations: const layouts = [
  [{ height: 720, width: 1280, x: 320, y: 180 }],
  [{ height: 450, width: 800, x: 80, y: 315 }, { height: 450, width: 800, x: 1040, y: 315 }],
  [{ height: 450, width: 800, x: 80, y: 45 }, { height: 450, width: 800, x: 1040, y: 45 }, { height: 450, width: 800, x: 560, y: 585 }],
  [{ height: 450, width: 800, x: 80, y: 45 }, { height: 450, width: 800, x: 1040, y: 45 }, { height: 450, width: 800, x: 80, y: 585 }, { height: 450, width: 800, x: 1040, y: 585 }],
  [{ height: 337, width: 600, x: 20, y: 100 }, { height: 337, width: 600, x: 650, y: 100 }, { height: 337, width: 600, x: 1280, y: 100 }, { height: 337, width: 600, x: 340, y: 640 }, { height: 337, width: 600, x: 980, y: 640 }],
  [{ height: 337, width: 600, x: 20, y: 100 }, { height: 337, width: 600, x: 650, y: 100 }, { height: 337, width: 600, x: 1280, y: 100 }, { height: 337, width: 600, x: 20, y: 640 }, { height: 337, width: 600, x: 650, y: 640 }, { height: 337, width: 600, x: 1280, y: 640 }]
]; That might look overwhelming, but consider that each element in the outer array element contains an array of compositions for each video. If there are 3 participants, we can reference the third element in the outer array, and the position of the participant id in the array will determine which composition will apply to that video. participantIds We can modify our function to grab the proper composition and use those values when we add the video to the broadcast client. renderVideosToClient() const renderVideosToClient = async (participant, stream) => {
  const participantId = participant.id;
  const videoId = `video-${participantId}`;

  // get the index of this participantId
  const pIdx = participantIds.indexOf(participantId);

  let composition = layouts[participantIds.length - 1][pIdx];
  config.index = 2;

  const mediaStream = new MediaStream();
  mediaStream.addTrack(stream.mediaStreamTrack);
  broadcastClient.addVideoInputDevice(mediaStream, videoId, composition);
}; But remember - if we only do this when a participant is added, the previous video compositions will still reflect the composition that was applied when they were added. That is where the function comes into the picture. updateVideoCompositions() Here we loop over the array, grab the proper composition from , and use the ( ) method of the . participantIds layouts updateVideoDeviceComposition() docs broadcastClient const updateVideoCompositions = async () => {
  let idx = 0;
  for (const p of participantIds) {
    const videoId = `video-${p}`;
    let config = layouts[filteredParticipantIds.length - 1][idx];
    config.index = 2;
    broadcastClient.updateVideoDeviceComposition(videoId, config);
    idx = idx + 1;
  }
}; We should also make sure that when a participant leaves the stage that we remove the participant id from the array and again update the composition for all videos. stage.on(StageEvents.STAGE_PARTICIPANT_STREAMS_REMOVED, (participant, streams) => {
  const participantId = participant.id;

  // remove participant id from array
  const pIdx = participantIds.findIndex(id => id === participantId);
  participantIds.splice(pIdx, 1);

  const videoTrackId = `video-${participantId}`;
  const audioTrackId = `audio-${participantId}`;
  if (broadcastClient.getVideoInputDevice(videoTrackId)) broadcastClient.removeVideoInputDevice(videoTrackId);
  if (broadcastClient.getAudioInputDevice(audioTrackId)) broadcastClient.removeAudioInputDevice(audioTrackId);
  const videoId = `${participantId}-video`;
  document.getElementById(videoId).closest('.participant-col').remove();
  updateVideoCompositions(); 
}); As mentioned above, you'll most likely want to limit the amount of videos that are added to the live stream via the broadcast client. You might want to add a static image instead of the final video to show that there are more participants than what is shown: Summary In this post, we learned one approach for dynamic layouts when broadcasting a multi-host stage with Amazon IVS. In a future post, we'll look at additional options for broadcasting with multiple hosts. As always, if you have any questions or comments, please leave them below. Also published here

How to Create a Dynamic Layout for Multi Host Broadcasts With Amazon IVS

Cómo crear un diseño dinámico para transmisiones de varios hosts con Amazon IVS

Comment créer une mise en page dynamique pour les diffusions multi-hôtes avec Amazon IVS

अमेज़ॅन आईवीएस के साथ मल्टी होस्ट ब्रॉडकास्ट के लिए डायनामिक लेआउट कैसे बनाएं

Amazon IVS を使用してマルチホスト ブロードキャスト用の動的レイアウトを作成する方法

Como criar um layout dinâmico para transmissões de vários hosts com o Amazon IVS

Cách tạo bố cục động cho truyền phát nhiều máy chủ với Amazon IVS

如何使用 Amazon IVS 创建多主机广播的动态布局

Building .NET Document API Layouts Using Flat Element Hierarchy

What is Masonry Layout? Masonry layout is when items of varying sizes are laid out so there aren't any uneven gaps. Usually, when items are in a grid view, they are either aligned row-wise, column-wise, or both. But in a masonry layout, even if there is a shorter element in a row or column, the next element will take up the space. How to achieve Masonry Layout? There are many ways to achieve this, but one of the best ways is to use and use the function. So let’s get started. grid-template-columns repeat() The grid-template-columns property In addition to explicit column sizing, one of the most valuable and practical aspects of CSS Grid is the ability to repeat columns until they are filled and then automatically place items in them. In particular, the option to specify the number of columns we want in the grid and then give the browser control of those columns' responsiveness results in fewer columns being displayed on smaller viewport sizes and more columns being displayed as the screen width increases. This is achieved by using the repeat() function and the auto-placement keywords. To summarize, the function allows us to repeat columns as many times as needed. For example, if we are creating a 12-columns grid, we can write the following: repeat() .grid {
   display: grid;

  /* define the number of grid columns */
  grid-template-columns: repeat(12, 1fr);
} By using the directive, the browser is instructed to divide the available space among the columns so that each one receives an equal share. That is, regardless of how large it is, the grid in this example will always have 12 columns. However, this is not good enough because the content will be too squeezed on smaller viewports. 1fr So we need to specify a minimum width for the columns, making sure they don’t get too narrow. We can do that by using the function. minmax() grid-template-columns: repeat(12, minmax(300px, 1fr)); But because of the way Grid functions, the row will overflow. We're explicitly instructing the browser to repeat the columns 12 times per row, so even if the viewport width is too small to fit them all with the new minimum width requirement, the column won't wrap into new rows. CSS To achieve wrapping, we can use the or keywords. auto-fit auto-fill grid-template-columns: repeat(auto-fit, minmax(300px,1fr)); By using these keywords, we instruct the browser to take care of element wrapping and column sizing for us, causing elements that would otherwise overflow to wrap into rows. This is how the grid looks now: But this is not the masonry layout. So how to achieve it? Let’s see. and property The grid-column grid-row The and properties specify the grid item's size and location within a grid layout. Thus, we are able to specify the width or height of a single grid item within the grid. And to do that, we can use the keyword. grid-column grid-row span To increase the width of the first grid item we can write: .grid-item: nth-child(1)
    {
        grid-column: span 2;
        grid-row: span 1;
    } The first grid cell will therefore span two columns and have the following appearance: Similarly, if we want to increase the height of the second grid item, we can write: .grid-item: nth-child(2)
    {
        grid-column: span 1;
        grid-row: span 2;
    } The second grid cell will therefore span two rows and have the following appearance: In a similar manner, if we span every grid item in the desired manner, we will obtain the following: However, if the number of grid items is excessive, it won't be possible to specify a precise height and width for each grid item. So instead, we can assign the values dynamically: .grid-item: nth-child(7n+1) {
        grid-column: span 2;
        grid-row: span 1;
    }

.grid-item: nth-child(7n+2) {
        grid-column: span 1;
        grid-row: span 2;
    }

.grid-item: nth-child(7n+4) {
        grid-column: span 1;
        grid-row: span 2;
    }

.grid-item: nth-child(7n+5) {
        grid-column: span 3;
        grid-row: span 1;
    } And here is the output: But is this enough? Let’s take it to the next level by adding some perspective. We can achieve this by adding perspective() and using the transform() property: .active
{
    transform: perspective(18cm) rotate(20deg);
    transform-style: preserve-3d; 
    transform-origin: left;
} Additionally, we have a menu bar that, when selected, switches the grid from a regular grid to one with perspective. We can use JavaScript for that: menu.onclick=()=>{
 grid.classList.toggle('active');
} And the final output is: Let me know in the comments below! Did you like this article? Want to know which is the most versatile JavaScript solution for data visualization? Read here: https://techvariable.com/blogs/the-most-versatile-js-solution-to-data-visualization-d3-js/

How to Build a Masonry Layout Using CSS

Cómo construir un diseño de mampostería usando CSS

Comment construire une disposition de maçonnerie à l'aide de CSS

CSS का उपयोग करके मेसनरी लेआउट कैसे बनाएं

CSS を使用して組積造レイアウトを構築する方法

Como construir um layout de alvenaria usando CSS

Cách xây dựng bố cục nề bằng CSS

如何使用 CSS 构建砌体布局

The easiest way to make your app responsive for all screen sizes (Mobile, Tablet, and Desktop) My introduction to the "Flutter" framework came while developing a mobile version of an IoT web app, which allowed me to focus solely on creating a responsive screen for mobile devices. However, my perspective changed during my third project when my boss tasked me with streamlining the process of goods entering and leaving the warehouse, making it paperless. Until then, workers had to print documents before receiving or picking up goods. To achieve this, we decided to develop a Warehouse App to be used on Tablet devices, which required me to learn how to create widgets that could cater to larger screens within the app. Flutter After learning from several sources, I decided to make the app responsive for all devices. As well as using Tablets, Workers could also install apps on their phones and also open apps from desktops in the warehouse. Here are 3 methods, I picked along the way, that you can employ when making responsive layouts in apps. Flutter Table of Contents Dynamic Padding | ⭐️ Layout Builder | ⭐️⭐️⭐️ extension BuildContext | ⭐️⭐️⭐️⭐️⭐️ Live demo on Dartpat ( in case you want to try it first) Responsive Padding Layout Builder Extension Builcontext Responsive GridView Dynamic Padding | ⭐️ You might think it's unresponsive, but it's one solution for dealing with wide screens. It works by adding horizontal padding as the parent widget. The padding value will be set dynamically based on screen width. Let's have a look at the code below: import 'package:flutter/material.dart';

class ResponsivePadding extends StatelessWidget {
  final Widget child;
  const ResponsivePadding({
    Key? key,
    required this.child,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Padding(
      padding: MediaQuery.of(context).size.width > 650
          ? EdgeInsets.symmetric(
              horizontal: MediaQuery.of(context).size.width / 3.8)
          : const EdgeInsets.all(0),
      child: child,
    );
  }
} You can create a separate file for the above code. Then, use it whenever you need to limit the screen width. All you need to do is wrap your screen with the ResponsivePadding : widget @override
Widget build(BuildContext context) {
  return ResponsivePadding(
    child: Scaffold()
.... Here’s the result: Layout Builder | ⭐️⭐️⭐️ This Builds a widget tree that can depend on the parent widget’s size. Unlike , this approach captures all screen sizes and sets their layout accordingly. We have three layouts: Mobile, Tablet, and Desktop, and use a distinct widget for each one. I learned this technique from TheFlutter Way on YouTube - you can access the video through the reference link. Dynamic Padding See the responsive code below: import 'package:flutter/material.dart';

class Responsive extends StatelessWidget {
  final Widget mobile;
  final Widget tablet;
  final Widget desktop;
  const Responsive({
    Key? key,
    required this.desktop,
    required this.mobile,
    required this.tablet,
  }) : super(key: key);

  /// mobile < 650
  static bool isMobile(BuildContext context) =>
      MediaQuery.of(context).size.width < 650;

  /// tablet >= 650
  static bool isTablet(BuildContext context) =>
      MediaQuery.of(context).size.width >= 650;

  ///desktop >= 1100
  static bool isDesktop(BuildContext context) =>
      MediaQuery.of(context).size.width >= 1100;
  
  @override
  Widget build(BuildContext context) {
    return LayoutBuilder(builder: (context, constraints) {
      if (constraints.maxWidth >= 1100) {
        return desktop;
      } else if (constraints.maxWidth >= 650) {
        return tablet;
      } else {
        return mobile;
      }
    });
  }
} From the code above, we have a and return a . As you can see, we have 3 constraints width. You can modify the value as you need. StatelessWidget LayoutBuilder : Example implementation : Generally, this is the smallest width, I want to display content vertically, so I need to scroll down to see all content, Mobile layout : it has a wider screen than that of a mobile device, and I want to combine vertical and horizontal views. Tablet : for a desktop size I think it's enough to display all content horizontally. Desktop I also varied the width of each child to see the difference. We can use it like the code below: @override
Widget build(BuildContext context) {
  return Responsive(
    mobile: mobileWidget,
    tablet: tabletWidget,
    desktop: desktopWidget,
  );
} Now we have 3 different layouts depending on screen size. You can create custom widgets for each layout. when the app is opened on different devices, they all have a corresponding look. Extension BuildContext | ⭐️⭐️⭐️⭐️⭐️ Okay, this is a fairly intermediate level but very decent and easy to use. We will use an extension method from Flutter and also a generic function. Let's start with the definition. A generic function is a function that is declared with type parameters. When called, actual types are used instead of the type parameters.[ ] ref With generic functions, we can use functions based on the type we declare. So it will be more dynamic. In Dartlang, we usually encounter this when a class or function is declared with type <T>. , introduced in Dart 2.7, are a way to add functionality to existing libraries.[ ] Extension Methods ref Btw, I found this very interesting idea on Twitter. https://twitter.com/millergodev/status/1573545322457927680?s=20&t=a_eEgIMPf1uyTwoRHiUb5w&embedable=true In Flutter we often use context. takes care of widget location in the widget tree. So…. we will have context in all widget trees. Without context, the widget will not render. BuildContext We will create an extension method for BuildContext to handle the Responsive layout. Look at the code below: extension Responsive on BuildContext {
  T responsive<T>(
    T defaultVal, {
    T? sm,
    T? md,
    T? lg,
    T? xl,
  }) {
    final wd = MediaQuery.of(this).size.width;
    return wd >= 1280
        ? (xl ?? lg ?? md ?? sm ?? defaultVal)
        : wd >= 1024
            ? (lg ?? md ?? sm ?? defaultVal)
            : wd >= 768
                ? (md ?? sm ?? defaultVal)
                : wd >= 640
                    ? (sm ?? defaultVal)
                    : defaultVal;
  }
} With this method, we can achieve the same result as LayoutBuilder but with simpler code. @override
Widget build(BuildContext context) {
  return Container(
    child: context.responsive<Widget>(
      mobileWidget, // default 
      md: tabletWidget, // medium
      lg: desktopWidget, // large
    ),
  );
} As I said earlier, this method uses a generic function. We can define functions to return any type of value. Let's try the example below. @override
Widget build(BuildContext context) {
  return GridView.count(
    crossAxisCount: context.responsive<int>(
      2, // default
      sm: 2, // small 
      md: 3, // medium
      lg: 4, // large 
      xl: 5, // extra large screen
    ),
....... This is another example with grid view in "Flutter". Result: Ok, that's 3 ways to give your Flutter app a responsive layout. You can change the breakpoint value as needed. Thanks for reading, please share if this article helped you Original story published on Easyread Reference: Flutter Fully Responsive Design for Web, Tab, and Mobile — YouTube LayoutBuilder class — widgets library — Dart API (flutter.dev) Extension methods | Dart

Creating Responsive Flutter App Layouts for All Screen Sizes

CSS Grid is a layout system for the web, allowing developers to create complex, responsive designs using rows and columns. Grid is used to make complex web design layouts more easily. Let’s get into it. First things first, we have to make a div and give it a class of containers or anything you want. <div class="container">
  <div>one</div>
  <div>two</div>
</div> After creating our div, let's go to our CSS and start applying the grid to it. we assign our container a display property of the grid. .container{
display: grid;
} Now, After assigning display: grid; nothing happens, because we didn't set the width of the container, so for that, there is a different property in Grid to set the width which is "grid-template-columns". .container{
display: grid;
grid-template-columns: 50% 50%;
} So, this gives us Two Columns of each having 50% width. NOTE: There is a Short-hand property to write grid-template-columns, .container{
display: grid;
grid-template-columns: repeat(2, 50%);
} The "repeat()" property works the same as the above values which are 50% & 50%, but, here instead of writing 50% twice, we set it to repeat() and then "2" which means to create "2" columns & then "50%" which means to set a width of 50%. KEY-POINT:- Instead of using % or pixels, we use fr(fraction) in the grid-template-columns value. for ex. 1fr, 2fr, 1/2fr ......etc. .container{
display: grid;
grid-template-columns: repeat(2, 1fr);
} "fr" works very well and it's very important to add for the responsiveness of the website. Now, if we want spaces b/w our grids, then the property for that in Grid is "gap or grid-gap or row-gap/column-gap". .container{
display: grid;
grid-template-columns: repeat(2, 1fr);
grid-gap: 10px
} This grid-gap property gives us a space of 10px around our rows and columns. If you want to add a gap in b/w rows or columns, you can use a property of row-gap or column-gap. .container{
display: grid;
grid-template-columns: repeat(2, 1fr);
row-gap: 10px;
} 

or or or

.container{
display: grid;
grid-template-columns: repeat(2, 1fr);
column-gap: 10px;
} Now, in order to add some height to our container, we use a property in grid called "grid-template-rows". .container{
display: grid;
grid-template-columns: repeat(2, 1fr);
grid-gap: 10px;
grid-template-rows: 200px;
} Now from the above given example, you might think that what if our content is more than 200px and then our content starts overflowing and it doesn't look good on layouts, So what might be the solution here. You must be thinking, oh, I wish there would be a property that adjusts itself according to the content...... and guess what, there is a property for this called But there's a catch in "grid-template-rows", "grid-auto-rows". .container{
display: grid;
grid-template-columns: repeat(2, 1fr);
grid-gap: 10px;
grid-auto-rows: minmax(200px, auto);
} Now, in the "grid-auto-rows" property you write and in between parenthesis, you add In the above examples, we add as a and as a minmax(), two values. "200px" minimum value "auto" maximum value. If our content is less than 200px or exactly 200px there won't be any issue and it gets fit in easily, but if our content is more than 200px, let's say 300px, then our auto property works and our rows will adjust according to the content size and fit in easily without overflowing. There are more grid properties, but I think if you practice the ones shown above, you will easily create a very good and responsive layout. Keep in mind that by doing just the above-shown examples you cannot create a layout, you have to add the margin, padding, and all other basic properties. That's it for the CSS Grids from my side, feel free to leave feedback and areas where I should improve myself as I am currently learning...... Also published here.

A Beginner's Guide to CSS Grid Layout

This article will help improve the interaction between designers and layout artists to minimize errors and increase productivity. Do not take the article as the only correct approach. The article is rich in practical examples. It will be useful to different specialists. The design is the basis of a quality layout and helps you successfully continue the development of a web application. Criteria for good design Standard properties of design elements (colors, fonts, sizes, padding, etc.) The principle of reuse. Changing some elements should lead to transformations of these elements in other parts of the layout. You should avoid copying elements and reuse them instead. We are talking about the use of styles and components in figma, i.e. fonts, colors, padding, etc. The order of layers and clear naming – first of all, this reflects your level of professionalism. You need to take the process responsibly. Work out the issue of the functioning of the project on mobile and touch devices. Keep in mind that there is no hover event on these devices. Don’t forget to use this in your layouts (there is a hover text on desktop, while there is no such case on mobile devices). To simplify the work of layout artists, the designer should make videos of the created animations. Layout recommendations Pixel Perfect is an outdated solution. It prevailed for raster layouts, in which it was not possible to refine the dimensions of elements. At this stage, browser extensions were used to overlay design images. There is no need to use this approach. You should not use global tag selectors for such elements as a, li, ui, h, p, etc. Create classes for more precise selection. For example, you can bind the wrapper class to body .main h1 {}. Globally, h1 is bad, .h1 is good. Remember the principle of reusability! Try not to set the height of elements (input button, etc.) with padding if they have a static height in the design. The height of elements should be set in pixels. So, the designer sets specific pixel dimensions for an element, and changing the number of lines or internal content will affect the original dimensions. If this cannot be avoided, for example, a button is a 2-line font wrap, be careful with the internal content. Perhaps you should create an additional class. Use size types correctly. For layout elements, it is best to use pixels rather than other units of measurement. The design is usually created in pixels, so you should not interfere with the original parameters. Percentages also need to be applied carefully. If you are using anything other than 25% 50% 100%, you are probably doing something wrong. 50% if we divide equally 2 blocks inside 1 parent, and 25% if it is about 4 blocks. For fonts and typography, you should use relative values ​​rem, em, and %. Setting the font size to px prevents adjusting the font size in web browsers, which some people use. Using ready-made ui systems and bootstrap If you use bootstrap and other ui systems in projects where all elements are custom and can accept any logic and forms, you will most likely generate additional wrappers and crutches, while adding unused functionality in the form of js and style code. Therefore, I would recommend avoiding this and customizing everything to fit your needs if you use custom visuals. Bootstrap often has a lot of things that we do not need to use. So, we remove one part and customize the other. Another problem may arise when changing the ui of the libraries used in the frameworks. If bootstrap, or any other ui system, is easy to adapt to your needs and doesn’t require complex customization, you can use it without any problems. Let’s analyze the patterns The atomic class approach will be used as an example. This may slightly increase the amount of html code. However, this problem can be solved by creating a small number of accurate classes. The advantage of this method is the reuse of css styles, as well as the minimization of the number of class wrappers. Let’s consider color standards for elements, fonts, icons, etc. Create and reuse styles for colors. There is no need to use an eyedropper, inherit the color, or copy hex codes. A small number of shades of the same color in the project will help you avoid unnecessary confusion. Don’t create “50 shades of gray”. The project needs about 6 primary and 4 secondary colors. Transferring color styles to a ui kit (dashboard) is necessary to get information about color codes and transfer it without using Figma. For example, you can send a printed brand book to your customer. The style names in figma must match the color variable names in the code. This will help the developer navigate and avoid opening figma to view the color. Examples of names $color-main : #464c54 ; $color-primary : #ff2e00 ; $color-primary-hover : #d72d00 ; $color-primary-active : #bd2200 ; $color-success : #25b782 ; $color-blue : #7da9e0 ; $color-withe : #f4f4f4 ; $color-gray-light : #ccd1d9 ; $color-gray : #8c9299 ; $color-element : #545c66 ; $color-element-light : #656d78 ; Let’s create color and fill classes for use in html. } }
} @mixin color ( $name , $color ) { .bg- #{ $name }  { background : $color !important ; .color- #{ $name } { color : $color !important ; Connect @include color ( 'base' , $color-main ); @include color ( 'primary' , $color-primary ); @include color ( 'success' , $color-success ); @include color ( 'blue' , $color-blue ); @include color ( 'withe' , $color-withe ); @include color ( 'light' , $color-gray-light ); @include color ( 'gray' , $color-gray ); @include color ( 'element' , $color-element ); @include color ( 'element2' , $color-element-light ); Use bg-{{name}} .bg-primary .bg-danger for `background-color` Use color-{{name}} for `color` The multiplicity of indents and sizes The multiplicity of indents and sizes is the designer’s observance of the principle of dividing all such dimensions by the same integer. The standard is 4px, which means that all indents and sizes must be the product of 4 by some integer. These are 4px, 8px, 12px, 16px, 20px, etc. It is allowed to use 1px and 2px. If necessary, the multiplicity can be changed (for example, 22px or 11px), but it is better to at least keep a multiplicity of 2px if the base is 4px. Otherwise, we will have to divide the pixel when centering the elements. For example, a button has a font size of 11px and a height of 40px. We place our font in the center of the button. 40 - 11 = 29/2 = 14.5 (top and bottom indent) The browser can handle pixel division – that’s not a problem. There is the question of aesthetics and ease of page layout process. When splitting a layout along a pixel grid in figma, you won’t have to go beyond its boundaries. Don’t forget to put the information on the indents into the ui kit, which must contain all the design agreements. Create a sheet that is necessary to generate classes: ); $sizes : ( 0 : 0 , 4 : 4px , 8 : 8px , 12 : 12px , 16 : 16px , 20 : 20px , 24 : 24px , 28 : 28px , 32 : 32px , 36 : 36px , 40 : 40px , 44 : 44px , 48 : 48px , Then use a mixin to create classes: } } } } } } } } } } } } } }
  }
} @mixin size-classes( $screen : '' ) { @each $index , $size in $sizes { .m #{ $screen }-#{ $index } { margin : $size !important ; .mx #{ $screen }-#{ $index } { margin-right : $size !important ; margin-left : $size !important ; .my #{ $screen }-#{ $index } { margin-top : $size !important ; margin-bottom : $size !important ; .ml #{ $screen }-#{ $index } { margin-left : $size !important ; .mr #{ $screen }-#{ $index } { margin-right : $size !important ; .mt #{ $screen }-#{ $index } { margin-top : $size !important ; .mb #{ $screen }-#{ $index } { margin-bottom : $size !important ; .p #{ $screen }-#{ $index } { padding : $size !important ; .px #{ $screen }-#{ $index } { padding-right : $size !important ; padding-left : $size !important ; .py #{ $screen }-#{ $index } { padding-top : $size !important ; padding-bottom : $size !important ; .pl #{ $screen }-#{ $index } { padding-left : $size !important ; .pr #{ $screen }-#{ $index } { padding-right : $size !important ; .pt #{ $screen }-#{ $index } { padding-top : $size !important ; .pb #{ $screen }-#{ $index } { padding-bottom : $size !important ; } } } @include size-classes; @include app-classes; @include media(lg) { @include size-classes( '-lg' ); @include app-classes( '-lg' ); @include media(md) { @include size-classes( '-md' ); @include app-classes( '-md' ); @include media(sm) { @include size-classes( '-sm' ); @include app-classes( '-sm' ); I wouldn’t recommend creating classes for negative indents and adding more than 20 variations. In this case, we will create a lot of rarely used classes and greatly increase the css file for initial rendering. In our example, we create 1 size and add 14 classes (from the padding and margin mixin) * 4 (all resolutions) – 56 classes in total. So, it is worth reducing the number of sizes in the sheet. Creating variables: $size-0 : map-get( $sizes , 0 ); $size-4 : map-get( $sizes , 4 ); $size-8 : map-get( $sizes , 8 ); $size-12 : map-get( $sizes , 12 ); $size-16 : map-get( $sizes , 16 ); $size-20 : map-get( $sizes , 20 ); $size-24 : map-get( $sizes , 24 ); $size-28 : map-get( $sizes , 28 ); $size-32 : map-get( $sizes , 32 ); $size-36 : map-get( $sizes , 36 ); $size-40 : map-get( $sizes , 40 ); $size-44 : map-get( $sizes , 44 ); $size-48 : map-get( $sizes , 48 ); $size-52 : 52px ; $size-60 : 60px ; $size-64 : 64px ; $size-80 : 80px ; $size-84 : 84px ; $size-88 : 88px ; $size-100 : 100px ; Until the first size-52, we inherit sizes from $sizes. For the rest, it is enough to create sizes that are multiples of our approvals. Inside the team, it is necessary to prohibit developers from using sizes. They have to use variables like $size-4 $size-32, etc., and percentage values ​​are allowed only in the format of 100 50 25 percent. If you still have to deviate from this order, be sure to leave a comment. This will help you avoid misunderstandings and clarify that this is part of the design. } &__subcategories { max-width : 600px ; Use m`{-media}?`-`{size}` (x-axis, y-axis) for `margin`. Use p`{-media}?`-`{size}` (x-axis, y-axis) for `padding`. Create `icon-{size}` classes for icons Only 3 classes are most often needed: icon-16 icon-24 icon-32 fill: currentColor;
} } } } svg { width : 100% ; height : 100% ; .icon-16 { width : $size-16 ; height : $size-16 ; .icon-24 { width : $size-24 ; height : $size-24 ; .icon-32 { width : $size-32 ; height : $size-32 ; Font styles As in the case of colors and indents, all fonts must be brought into figma styles and put into a ui kit, without creating dozens of variations of size and thickness, as well as letter and line spacing. As a rule, the following is enough: sizes – h1, h2, h3, h4: default text, small text. Styles – regular, medium, bold. The layout artist needs to correctly connect our fonts, which means specifically telling the browser where to download regular, bold fonts, etc. Otherwise, the browser will create its bold style, which won’t match the layout. Use classes to set fonts for elements like .h1, .h2, or at least @mixin h1. Mixins are bad since they duplicate properties instead of reusing them. When working with the layout, select the desired font using font-weight. Connect } } @font-face { src : url( 'https://fonts.gstatic.com/s/rubik/v14/iJWKBXyIfDnIV7nBrXw.woff2' ) format( 'woff2' ); font-family : 'Rubik' ; font-weight : 100 500 ; font-style : normal; font-display : swap; @font-face { src : url( 'https://fonts.gstatic.com/s/rubik/v14/iJWKBXyIfDnIV7nBrXw.woff2' ) format( 'woff2' ); font-family : 'Rubik' ; font-weight : 600 800 ; font-style : normal; font-display : swap; Using mixins for base classes: }
} .h3 { @include h3; @include media(md) { @include h4; user-select: text; }
} } } } } } } }
} @mixin font( $size : 16px , $line-height : 22px , $letter-spacing : 0.1px , $weight : 400 , $bottom : false) { margin : 0 ; font-family : $font ; font-weight : $weight ; font-size : $size ; line-height : $line-height ; letter-spacing : $letter-spacing ; @if $bottom { margin-bottom : $bottom ; @mixin h1 { @include font( 46px , 52px , 2px , 600 , $size-32 ); @mixin h2 { @include font( 30px , 30px , 1.5px , 500 , $size-24 ); @mixin h3 { @include font( 22px , 26px , 0.5px , 400 , $size-16 ); @mixin h4 { @include font( 18px , 26px , 0.3px , 400 , $size-8 ); @mixin text { @include font; @mixin text-sm { @include font( 14px , 20px ); @mixin text-default { @include text; @include media(tablet) { @include text-sm; Adding margin bottoms to headings is acceptable. These indents are usually standard for each font size. You can remove indentation like this: - .h1 .mb-0 Element properties The designer also puts all the repeating styles of the elements (shadows, radii, borders) into the ui kit. There is no need to create a lot of variations. The layout looks like this: $font : 'Rubik' , sans-serif; $radius-block : $size-6 ; $radius-element : $size-6 ; $border-element : $size-2 ; $show-block : 0 0 $size-38 rgba( $color-element , 0.1 ); $animate-time : 0.2s ; Checkpoints The designer specifies the checkpoints for your application and puts the information into the ui kit. Typically, the sizes correspond to screen sizes of different devices. Create variables: ); $breakpoints : ( xl: 1200px , lg: 992px , md: 768px , sm: 576px , Create a mixin for ease of use of media conditions: }
} @mixin media( $Device ) { @media screen and ( max-width : map-get( $breakpoints , $Device ) - 1px ) { @content ; Utility classes } } } } } } } } } } } } } } } } } } } } } } } } } } } } } }
} @mixin app-classes( $screen : '' ) { .d #{ $screen }-n { display : none !important ; .d #{ $screen }- b { display : block !important ; .d #{ $screen }-f { display : flex !important ; .fw #{ $screen }-w { flex-wrap : wrap !important ; .fw #{ $screen }-n { flex-wrap : nowrap !important ; .fd #{ $screen }-c { flex-direction : column !important ; .fd #{ $screen }-r { flex-direction : row !important ; .fb #{ $screen }-100 { flex-basis : 100% !important ; .ai #{ $screen }-c { align-items : center !important ; .ai #{ $screen }-fs { align-items : flex-start !important ; .ai #{ $screen }-fe { align-items : flex-end !important ; .as #{ $screen }-fs { align-self : flex-start !important ; .as #{ $screen }-fe { align-self : flex-end !important ; .as #{ $screen }-c { align-self : center !important ; .jc #{ $screen }-fe { justify-content : flex-end !important ; .jc #{ $screen }-fs { justify-content : flex-start !important ; .jc #{ $screen }-c { justify-content : center !important ; .jc #{ $screen }-sb { justify-content : space-between !important ; .bg #{ $screen }-n { background : none !important ; .br #{ $screen }-n { border : none !important ; .w #{ $screen }-100 { width : 100% !important ; .h #{ $screen }-100 { height : 100% !important ; .w #{ $screen }-50 { width : 50% !important ; .h #{ $screen }-50 { height : 50% !important ; .w #{ $screen }-25 { width : 50% !important ; .h #{ $screen }-25 { height : 50% !important ; .f #{ $screen }-l { font-weight : 300 ; .f #{ $screen }-r { font-weight : 400 ; .f #{ $screen }-m { font-weight : 600 ; .f #{ $screen }- b { font-weight : 800 ; This is the class approach to layout design. For example, we often need to align blocks horizontally: in this case, d-f will be enough, and we won’t have to consistently create wrapper classes. Use `d-f` for `display-flex: flex`. Use `ai-c` for `align-items: center`. The list can be constantly replenished as needed. If the property consists of 2 words, use the letters of the words `text-align` = `ta`. If the property consists of 1 letter and does not conflict with others, use `display` = `d`. In case of conflict between the first and last letters, use `border` = `br` or part of the word according to the logic `background` = `bg`. Try to use class layout without any scss variables and mixins. `class="d-f m-4 m-md-4"` – permissible. `class="d-f m-4 m-md-4 d-f m-4 m-md-4 d-f m-4 m-md-4 d-f m-4 m-md-4"` – bad. In such cases, a class is created with a description of the properties inside it. `class="d-f custom-class"` – not forbidden, but sometimes it is more convenient and preferable to write the property inside the class: `display: flex`. Make it a rule not to write more than 5 classes in a block. Z-index Connect `@include z-index(key name)`. The z-index values ​​are set in increments of 10 to leave space for errors and tweaks. When adding a new key, you need to take into account any z-index conflicts that may occur: ); $z-index : ( modal: 30 , header: 20 , menu: 10 , default: 1 , Conclusion You need to thoroughly approach the process of layout design. This will help you avoid difficulties in the implementation of the project and ensure easy, unpretentious cooperation between specialists in various fields.

Layout Patterns: How to Unite Layout Artists and Designers

Welcome to part four of "Building a GatsbyJS Blog!" In this post, we'll continue building a beautiful and fully functional blog with GatsbyJS. In the previous installment, we produced our blog's foundation by creating a "Layout" component that provides a cohesive and consistent design across all pages. Now, we're ready to take our blog to the next level by adding featured images. Featured images are an essential part of any blog as they help to draw the reader's attention and make your content more visually engaging. In this post, we'll show you how to add images to the Layout component we created in part two of the series. We'll also show you how to define unique images for each blog post using the frontmatter of the post's MDX file. With these techniques, you'll be able to create a visually stunning and professional-looking blog that stands out from the crowd. So let's get started! Table of Contents Adding featured images to main pages Adding blog post featured images Showing images in the blog list. Conclusion Adding featured images to main pages Every page in our blog will have an image above the main content, right below the main navigation bar. The idea is to give a splash of color and something to catch the reader's eye. The featured image is also critical for blog posts as you want to have that image appear in Twitter and Facebook posts when you start doing search engine optimization. : An image before the main content is a classic look for websites and blogs. But you may decide it's too dated or has lousy SEO, which is totally cool. So I'm not necessarily advocating for this style (although I ). NOTE use it on my own website PageLayout updates Open up the file and modify it as such: ./src/components/PageLayout.tsx // ./src/components/PageLayout.tsx
import { GatsbyImage, IGatsbyImageData } from 'gatsby-plugin-image';
import React from 'react';
import { PageFooter } from '../page-footer';
import { PageHeader } from '../page-header';

interface PageLayoutProps {
  image?: IGatsbyImageData | null;
  title?: string;
}

export const PageLayout: React.FC<React.PropsWithChildren<PageLayoutProps>> = ({
  children,
  image,
  title,
}) => {
  return (
    <main className="font-sans font-light">
      <PageHeader />
      {image && (
        <div className="relative mb-12 flex h-96 items-center justify-center">
          <GatsbyImage image={image} alt="" className="absolute inset-0" />
          {title && (
            <div className="z-20 mx-auto max-w-5xl">
              <h1 className="text-4xl font-bold text-white sm:text-5xl">
                {title}
              </h1>
            </div>
          )}
          {/* Darken the background image a little so the text shows up better */}
          <div className="absolute inset-0 z-10 bg-gray-900 opacity-30" />
        </div>
      )}
      <div className="mx-auto mb-12 max-w-5xl">{children}</div>
      <PageFooter />
    </main>
  );
}; Find an image We will pass the image data and the page title to the layout component from our pages. But before we do that, we will have to find an image and put it in our folder. So go ahead and locate a nice picture. For example, I use for many of my stock images. ./src/images Pexels Once you find an image, move it over to the directory: ./src/images mv /path/to/downloaded/image.jpg ./src/images/header.jpg Update the Home page Now we are ready to start adding the image to our pages. Let's start with the "Home" page. // ./src/pages/index.tsx
import { graphql, HeadFC, PageProps } from 'gatsby';
import { getImage } from 'gatsby-plugin-image';
import * as React from 'react';
import { PageLayout } from '../components/page-layout';

const IndexPage: React.FC<PageProps<Queries.IndexPageQuery>> = ({ data }) => {
  const image = data.headerImage
    ? getImage(data.headerImage.childImageSharp)
    : null;

  return (
    <PageLayout image={image} title="My Gatsby Blog">
      <div className="container mx-auto px-4 lg:px-0">
        <span className="text-lg">This is my Gatsby Blog home page!</span>
      </div>
    </PageLayout>
  );
};

export default IndexPage;

// This query will be run during the GatsbyJS build process when creating our
// pages. The data will be passed to our page component as a `data` property.
export const pageQuery = graphql`
  query IndexPage {
    headerImage: file(relativePath: { eq: "header.jpg" }) {
      childImageSharp {
        gatsbyImageData(layout: FULL_WIDTH)
      }
    }
  }
`;

export const Head: HeadFC = () => <title>Home Page</title>; : The file name argument needs to match the file name of the file you added to the folder. So, double-check that you've got that file name correct. NOTE relativePath ./src/images After the development server updates, you should see a home page that looks something like this: To get the same result on your "About" page and "Blog List" pages, do the same thing we did above to the and page components. .src/pages/about.tsx ./src/pages/blog.tsx : If you want different images for each page, download additional images and move them to the folder. Then, update the for each page component to gather the correct image data by updating the accordingly. TIP ./src/images pageQuery relativePath Adding blog post featured images So far, we have updated our main pages to show featured images. Now we want to add featured images to all of our blog posts. The trick is that we can't define the featured image using a as we did for our main pages since we're using MDX to generate these pages. pageQuery This is where the frontmatter for each blog post comes in. We will use the frontmatter section of each MDX file to define a property and use that property to find the image and display it in the blog post. featuredImage Update the frontmatter Update each of your blog post MDX files with frontmatter that looks like this: ---
date: 2023-02-18 01:00:00
slug: my-first-blog-post
title: My First Blog Post
author: John Smith
featuredImage: ./featured.jpg
--- : Make sure to add this to each of your blog posts. NOTE After adding the markdown, you probably need to restart the development server to ensure the frontmatter is parsed correctly. Add some image files. Obviously, you'll need to have image files before you see any images! So, again, go find some lovely pictures from your favorite stock image site. Once you have downloaded a few images, add them to the blog post directory: mv /path/to/downloaded/image.jpg .src/content/<blog-directory>/featured.jpg : You'll want to ensure you have an image for each of your posts; otherwise, you might see some errors when GatsbyJS is building your queries. NOTE Update BlogPostTemplate.tsx We have updated the frontmatter to our blog posts and added images to each blog post folder. All we have to do now is hook things up. Open up the file and update it as follows: ./src/templates/BlogPostTemplate.tsx // ./src/templates/BlogPostTemplate.tsx
import { MDXProvider } from '@mdx-js/react';
import { graphql, PageProps } from 'gatsby';
import { getImage } from 'gatsby-plugin-image';
import React from 'react';
import { components, MainContent } from '../components/mdx-components';
import { PageLayout } from '../components/page-layout';

const BlogPostTemplate: React.FC<PageProps<Queries.BlogPostQuery>> = ({
  data,
  children,
}) => {
  const featuredImage = data.mdx?.frontmatter?.featuredImage
    ? getImage(data.mdx.frontmatter.featuredImage.childImageSharp)
    : null;

  return (
    <PageLayout
      image={featuredImage}
      title={data.mdx?.frontmatter?.title ?? undefined}
    >
      <MainContent>
        <div className="mb-8">
          <span className="text-sm font-thin">
            By {data.mdx?.frontmatter?.author} on {data.mdx?.frontmatter?.date}
          </span>
        </div>
        <MDXProvider components={components}>{children}</MDXProvider>
      </MainContent>
    </PageLayout>
  );
};

export default BlogPostTemplate;

export const query = graphql`
  query BlogPost($id: String!) {
    mdx(id: { eq: $id }) {
      frontmatter {
        title
        author
        date(formatString: "MMMM DD, YYYY")
        featuredImage {
          childImageSharp {
            gatsbyImageData(layout: FULL_WIDTH)
          }
        }
      }
    }
  }
`; If you navigate to a blog post, you should now see the featured image! Show images in the blog list The last thing we want to do is update our blog list so that each post shows a preview of the featured image. Update the blog page We will update the query in our page component to do this. ./src/pages/blog.tsx // ./src/pages/blog.tsx
import { graphql, Link, PageProps } from 'gatsby';
import { GatsbyImage, getImage } from 'gatsby-plugin-image';
import React from 'react';
import { PageLayout } from '../components/page-layout';

const BlogPage: React.FC<PageProps<Queries.BlogPageQuery>> = ({ data }) => {
  const headerImage = data.headerImage
    ? getImage(data.headerImage.childImageSharp)
    : null;

  return (
    <PageLayout image={headerImage} title="Blog">
      <ul className="mx-auto max-w-3xl p-4 sm:p-0">
        {data.allMdx.edges.map(({ node }) => (
          <li key={node.id} className="mb-4 h-72 last-of-type:mb-0">
            <Link
              to={`/blog/${node.frontmatter?.slug}`}
              className="flex items-center overflow-hidden rounded-lg border border-gray-400"
            >
              <div className="flex-1 md:h-72 md:w-64">
                {node.frontmatter?.featuredImage && (
                  <GatsbyImage
                    image={
                      getImage(node.frontmatter.featuredImage.childImageSharp)!
                    }
                    alt=""
                    className="h-full w-full"
                  />
                )}
              </div>
              <div className="flex-1 p-6">
                <h2 className="mb-4 text-xl font-bold">
                  {node.frontmatter?.title}
                </h2>
                <span className="mb-2 block text-sm font-thin">
                  By {node.frontmatter?.author} on {node.frontmatter?.date}
                </span>
                <span className="block text-lg">{node.excerpt}</span>
              </div>
            </Link>
          </li>
        ))}
      </ul>
    </PageLayout>
  );
};

export default BlogPage;

export const query = graphql`
  query BlogPage {
    headerImage: file(relativePath: { eq: "header.jpg" }) {
      childImageSharp {
        gatsbyImageData(layout: FULL_WIDTH)
      }
    }
    allMdx(sort: { frontmatter: { date: DESC } }) {
      edges {
        node {
          id
          excerpt(pruneLength: 160)
          frontmatter {
            title
            author
            date(formatString: "MMMM DD, YYYY")
            slug
            featuredImage {
              childImageSharp {
                gatsbyImageData(layout: FULL_WIDTH)
              }
            }
          }
        }
      }
    }
  }
`; After those changes, your blog list page should look something like this: Conclusion With the addition of featured images to our GatsbyJS blog, we've taken a big step forward in creating a visually stunning and engaging platform for our readers. In addition, by using GraphQL queries to source images from our local filesystem and display them on our blog pages, we've also gained a deeper understanding of the power and flexibility of GatsbyJS. As we continue to build our blog, there will be many new challenges and opportunities to explore. In the next installment of "Building a GatsbyJS Blog," we'll discuss search engine and social media optimization. This will include topics such as metadata, sitemaps, and Open Graph tags, which are crucial for maximizing our blog's visibility and reach. We hope you've followed along and feel inspired to build your blog using GatsbyJS. If you have any questions or feedback, please don't hesitate to ask in the comments. And be sure to stay tuned for the next installment of the series, where we'll cover even more exciting GatsbyJS topics! Also published . here

How to Build a GatsbyJS Blog (Part 4): Layout and Featured Images

Welcome back to "Building a GatsbyJS Blog"! In this second part of the series, we'll focus on creating the Layout and pages for our blog. We'll start by creating a reusable component, the "Layout," which we'll use on all our pages to ensure a consistent design. Next, we'll make the pages for our blog and add some primary content. While we won't be adding the blog post pages just yet, we'll lay the groundwork for them in the next series post. So, let's get started with "Building a GatsbyJS Blog: Layout and Pages." Table of Contents Navigation and Routing Layout Pages Conclusion Navigation and Routing To begin with, though. Let's do some preparation. Define the navigation routes First, we will define our navigation routes in the section. This will help us later when we want to ensure our navigation links are uniform and have a single source of truth. gatsby-config.ts siteMetadata The section of your config is an excellent place to store any information about the site to which you will want easy access. Contact info, social media accounts, and navigation route definitions are perfect examples of things to store there. siteMetadata Open up your file and add the following code to the section: gatsby-config.ts siteMetadata siteMetadata: {
  title: `My Gatsby Blog`,
  siteUrl: `https://www.yourdomain.tld`,
  // ↓ Add this section
  navigation: [
    {
      name: 'About',
      path: '/about',
    },
    {
      name: 'Blog',
      path: '/blog'
    }
  ]
}, Create the hook. useMetadata We will often refer to the site metadata, so it's a good idea to have a reusable utility to quickly gather the information. We are going to do that by making use of a custom React hook we'll call . useMetadata Create a new folder and file called src/hooks/use-site-metadata.ts mkdir src/hooks
touch src/hooks/use-site-metadata.ts Then, add the following content to the file: // src/hooks/use-site-metadata.ts
import { graphql, useStaticQuery } from 'gatsby';

export const useSiteMetadata = () => {
  const data = useStaticQuery<{
    site: { siteMetadata: Queries.SiteSiteMetadata };
  }>(graphql`
    query SiteMetadataQuery {
      site {
        siteMetadata {
          title
          siteUrl
          navigation {
            name
            path
          }
        }
      }
    }
  `);

  return data.site.siteMetadata;
}; This custom hook can be added to any page or component in our codebase, making accessing the site's information easy. Of course, as we add more metadata, we'll need to update this query. You may prefer the file name ; I've settled into a specific naming convention and folder structure for all my TypeScript projects, and your mileage may vary. Feel free to modify this to whatever you prefer. No judgment! 😊 useSiteMetadata.ts : You'll need to restart the development server for the site metadata to be recognized and for the TypeScript types to be generated correctly. NOTE Create the Header component The Layout component we will create will have a header with a navigation section. We should build that component now, so we have it ready when we want to use it in the Layout. Create a new file for the page header: mkdir ./src/components/
touch ./src/components/PageHeader.tsx Add the following content to that file: // src/components/PageHeader.tsx
import { Link } from 'gatsby';
import { StaticImage } from 'gatsby-plugin-image';
import React from 'react';
import { useSiteMetadata } from '../../hooks/use-site-metadata';

export const PageHeader: React.FC = () => {
  const { title, navigation } = useSiteMetadata();

  return (
    <header className="bg-white">
      <div className="container mx-auto flex max-w-5xl items-center justify-between py-6">
        {title && (
          <Link
            to="/"
            className="flex items-center gap-2 px-4 sm:w-auto sm:pb-0 lg:px-0"
          >
            <StaticImage
              src="../../images/icon.png"
              alt={title}
              layout="fixed"
              height={35}
              width={35}
            />
            <span className="whitespace-nowrap text-xl font-bold uppercase">
              {title}
            </span>
          </Link>
        )}
        <nav className="flex w-full items-center justify-between text-sm sm:w-auto">
          <ul className="flex justify-between px-2 sm:px-0">
            {navigation?.map(
              (nav) =>
                nav?.path && (
                  <li key={nav.path} className="px-2 sm:px-4">
                    <Link to={nav.path}>{nav.name}</Link>
                  </li>
                )
            )}
          </ul>
        </nav>
      </div>
    </header>
  );
}; This defines the component we'll use for all our blog pages. In the next section, we will create a component for our pages. PageHeader Footer Create the Footer component We want a footer on each page with basic information about our blog. Right now, it's going to be sparse, but we might add to it later. Create the file for the footer: touch ./src/components/PageFooter.tsx And add the following content to that file: // src/components/PageFooter.tsx
import { Link } from 'gatsby';
import { StaticImage } from 'gatsby-plugin-image';
import React from 'react';
import { useSiteMetadata } from '../../hooks/use-site-metadata';

export const PageFooter: React.FC = () => {
  const { title, navigation } = useSiteMetadata();

  return (
    <footer className="bg-purple-200">
      <div className="container mx-auto flex max-w-5xl flex-col justify-evenly py-12 sm:flex-row">
        <div className="mb-12 sm:mb-0">
          {title && (
            <div className="mb-4 flex items-center justify-center gap-4 sm:-ml-6">
              <StaticImage
                className="inline-block"
                layout="fixed"
                height={20}
                width={20}
                src="../../images/icon.png"
                alt={title}
              />
              <span className="text-xl font-bold uppercase text-black">
                {title}
              </span>
            </div>
          )}
        </div>
        <div className="text-center sm:text-left">
          <ul className="flex flex-col items-center gap-4 sm:flex-row">
            {navigation?.map(
              (nav) =>
                nav?.path && (
                  <li key={nav.path}>
                    <Link className="underline" to={nav.path}>
                      {nav.name}
                    </Link>
                  </li>
                )
            )}
          </ul>
        </div>
      </div>
    </footer>
  );
}; Notice that we pull the navigation from . This is an example of how having that site metadata readily available can lead to better consistency across our pages. siteMetadata In the next section, we'll create a component and add the and . PageLayout PageFooter PageHeader Layout One of the keys to a successful blog is creating a sense of cohesion and continuity between pages. That's why in this part of the series, we will make a "Layout" component that will provide a consistent design across all our pages. The "Layout" component will consist of a header with navigation and a footer at the bottom. Create the PageLayout component As before, start by creating the file: touch ./src/components/PageLayout.tsx Then add this content to the file: // src/components/PageLayout.tsx
import React from 'react';
import { PageFooter } from '../page-footer';
import { PageHeader } from '../page-header';

export const PageLayout: React.FC<React.PropsWithChildren> = ({ children }) => {
  return (
    <main className="font-sans font-light">
      <PageHeader />
      <div className="mx-auto mb-12 max-w-5xl">{children}</div>
      <PageFooter />
    </main>
  );
}; Now we have a layout for all our pages! Notice that each page will be wrapped in a tag, where we set the default font family and weight. You can add other defaults here as well. <main> Pages It's time to start making some pages. First, we will edit the home page and create the "About" page. After that, the "Blog" page is a little more complex, so we will get to the "Blog" page in another post. The Home page To start, open up in your editor and erase everything already there. We don't like it. Then add this: ./src/pages/index.tsx // src/pages/index.tsx
import type { HeadFC, PageProps } from 'gatsby';
import * as React from 'react';
import { PageLayout } from '../components/page-layout';

const IndexPage: React.FC<PageProps> = () => {
  return (
    <PageLayout>
      <div className="container mx-auto px-4 lg:px-0">
        <h1 className="mb-8 text-4xl font-bold lg:text-5xl">My Gatsby Blog</h1>
        <span className="text-lg">This is my Gatsby Blog home page!</span>
      </div>
    </PageLayout>
  );
};

export default IndexPage;

export const Head: HeadFC = () => <title>Home Page</title>; If you reload the page, you should see something like this: The About page We want to do something very similar for the "About" page. Create the new page like so: touch ./src/pages/about.tsx : Any file inside the pages directory automatically becomes a page with a route corresponding to the file name and folder structure above it. TIP Then add the following content: import { graphql, HeadFC, PageProps } from 'gatsby';
import { GatsbyImage, getImage } from 'gatsby-plugin-image';
import * as React from 'react';
import { PageLayout } from '../components/page-layout';

const AboutPage: React.FC<PageProps<Queries.AboutPageQuery>> = ({ data }) => {
  const profileImage = data.profileImage
    ? getImage(data.profileImage.childImageSharp)
    : null;

  return (
    <PageLayout>
      <div className="container mx-auto px-4 lg:px-0">
        <h1 className="mb-8 text-4xl font-bold lg:text-5xl">About Us</h1>
        <span className="text-lg">
          Welcome to our blog's "About" page! We're glad you're here. This page
          is all about us, the people behind the blog. We're passionate about
          sharing our knowledge, opinions, and experiences with the world, and
          we hope you find our content informative and enjoyable.
        </span>
        <div className="mt-8 flex flex-col gap-4 sm:flex-row sm:items-center">
          {profileImage && (
            <div className="w-full sm:w-1/5">
              <GatsbyImage
                image={profileImage}
                alt="My Profile Image"
                className="w-full"
              />
            </div>
          )}
          <div className="flex-1 text-lg">
            Meet John, the tech enthusiast behind our Javascript blog. With over
            a decade of experience in web development, John has become a
            seasoned expert in all things Javascript. His passion for coding and
            his love of sharing knowledge have led him to create a blog that
            aims to help people master the art of Javascript and create amazing
            web experiences.
          </div>
        </div>
      </div>
    </PageLayout>
  );
};

export default AboutPage;

// This query will get run when the page is built, and the data will be passed in
// as the `data` property to the exported `AboutPage` above.
export const pageQuery = graphql`
  query AboutPage {
    profileImage: file(relativePath: { eq: "profile.jpg" }) {
      childImageSharp {
        gatsbyImageData(layout: FULL_WIDTH)
      }
    }
  }
`;

export const Head: HeadFC = () => <title>About Page</title>; : Notice that the "About" page uses the component just like the "Home" page. This gives each page a consistent look and feel without having to duplicate code. NOTE PageLayout The result should be something like this: Conclusion In this post, we made some significant progress toward creating our blog. First, we built a "Layout" component that will serve as the scaffolding for all of our pages, adding navigation elements, a header, and a footer to provide a consistent design across our site. We also created the home page and the "About" page to get a sense of how our blog will look and feel. However, we're just getting started. In the next section of the series, we'll focus on building the blog page and individual post pages. This is where the real magic happens, and we'll be able to start sharing our thoughts and expertise with the world. By the end of the next post, we'll have a fully functional blog with a robust design and Layout. Then, we'll be ready to start creating and sharing content with our readers. Also published here.

How to Build a GatsbyJS Blog (Part 2): Layout and Pages

Collection Compositional Layout is a new layout framework in the UIKit framework of iOS that was introduced in iOS 13. It provides a powerful and flexible way to build custom collection views in a modular and composable manner. With Collection Compositional Layout, you can define custom layouts for your collection views by composing various layout elements, such as sections, items, and groups, in a way that best suits your needs. You can use Collection Compositional Layout to define layouts that support dynamic content and varying item sizes, and you can also easily modify the layout of your collection view on the fly. The framework also includes a number of built-in layout elements that can be used to create common collection view layouts, such as grid, list, and nested groups. To use Collection Compositional Layout in your iOS app, you need to create an instance of , and then define one or more objects that represent the layout for each section in your collection view. You can then set the property of your layout to your instance, and the layout will be automatically applied to your collection view. UICollectionViewCompositionalLayout NSCollectionLayoutSection collectionView UICollectionView Today, we will thoroughly examine how to create such a screen using Collection Compositional Layout Data Source Initially, it is necessary to include two typealiases and a sections enum. I would like to utilize to easily update the content and add new content if necessary DiffableDataSource typealias DataSource = UICollectionViewDiffableDataSource<Section, PictureModel>
typealias DataSourceSnapshot = NSDiffableDataSourceSnapshot<Section, PictureModel> enum Section: Int, CaseIterable {
    case carousel
    case widget
    case pinterest
} I set up the data source for a collection view. The function takes in two parameters: an and a boolean value "animatingDifferences". The function starts by deleting all the items in the data source's snapshot using the "deleteAllItems" method. Then, it appends all the cases of the to the snapshot's sections. [PictureModel] Section Next, the function appends a range of pictures to each section. Finally, the function applies the snapshot to the data source using . The "animatingDifferences" parameter determines whether changes to the collection view are animated or not. apply private func configureDataSource(pictures: [PictureModel], animatingDifferences: Bool) {
    snapshot.deleteAllItems()
    snapshot.appendSections(Section.allCases)
        
    snapshot.appendItems(pictures[20...29].map { $0 }, toSection: .carousel)
    snapshot.appendItems(pictures[10...19].map { $0 }, toSection: .widget)
    snapshot.appendItems(pictures[0...9].map { $0 }, toSection: .pinterest)

    dataSource.apply(snapshot, animatingDifferences: animatingDifferences)
} For more information how data source works you can find there: iOS Tutorial: Collection View and Diffable Data Source Carousel Section The first section is “Carousel-style” or “Multiple banner” private static func carouselBannerSection() -> NSCollectionLayoutSection {
    //1
    let itemSize = NSCollectionLayoutSize(
          widthDimension: .fractionalWidth(1),
          heightDimension: .fractionalHeight(1)
    )
    let item = NSCollectionLayoutItem(layoutSize: itemSize)

    //2
    let groupSize = NSCollectionLayoutSize(
          widthDimension: .fractionalWidth(1),
          heightDimension: .fractionalWidth(1)
    )
    let group = NSCollectionLayoutGroup.horizontal(
          layoutSize: groupSize,
          subitems: [item]
    )
    //3
    let section = NSCollectionLayoutSection(group: group)
    section.orthogonalScrollingBehavior = .continuousGroupLeadingBoundary
    //4
    section.visibleItemsInvalidationHandler = { (items, offset, environment) in
          items.forEach { item in
              let distanceFromCenter = abs((item.frame.midX - offset.x) - environment.container.contentSize.width / 2.0)
              let minScale: CGFloat = 0.8
              let maxScale: CGFloat = 1.0 - (distanceFromCenter / environment.container.contentSize.width
              let scale = max(maxScale, minScale)
              item.transform = CGAffineTransform(scaleX: scale, y: scale)
         }
    }
    return section
} Let’s define the size of an individual item, which will be used as the basis for building the rest of the layout. This item will take up the full width and height of the available space, with a width dimension of and a height dimension of . .fractionalWidth(1) .fractionalHeight(1) A group is created with the defined item size and set to be arranged horizontally using . This group takes up the full width of the available space with a width dimension of and a height dimension equal to its width with . NSCollectionLayoutGroup.horizontal .fractionalWidth(1) .fractionalWidth(1) The is then created using the defined group, and its orthogonal scrolling behavior is set to , which means that the section will continuously scroll in the horizontal direction. NSCollectionLayoutSection .continuousGroupLeadingBoundary The of the section is set to a closure that performs a scaling transformation on each item based on its distance from the center of the visible area. The amount of scaling is determined by the distance from the center, with items closer to the center being scaled up and items farther away being scaled down. The minimum and maximum scale values are defined as and respectively. visibleItemsInvalidationHandler minScale maxScale Widget section This section is implemented almost the same way as the previous one. The only differences are in the configuration of the group private static func widgetBannerSection() -> NSCollectionLayoutSection {
    let itemSize = NSCollectionLayoutSize(
        widthDimension: .fractionalWidth(1),
        heightDimension: .fractionalHeight(1)
    )
    let item = NSCollectionLayoutItem(layoutSize: itemSize)
    item.contentInsets = .init(top: 0, leading: 5, bottom: 0, trailing: 5)

    //1
    let groupSize = NSCollectionLayoutSize(
        widthDimension: .fractionalWidth(0.2),
        heightDimension: .fractionalWidth(0.3)
    )
    let group = NSCollectionLayoutGroup.horizontal(
        layoutSize: groupSize,
        subitems: [item]
    )
    let section = NSCollectionLayoutSection(group: group)
    //2
    let supplementaryItem = NSCollectionLayoutBoundarySupplementaryItem(
        layoutSize: .init(
            widthDimension: .fractionalWidth(1),
            heightDimension: .absolute(30)
        ),
        elementKind: UICollectionView.elementKindSectionHeader, 
        alignment: .top
    )
    supplementaryItem.contentInsets = .init(
        top: 0,
        leading: 5,
        bottom: 0,
        trailing: 5
    )
    section.boundarySupplementaryItems = [supplementaryItem]
    section.contentInsets = .init(top: 10, leading: 5, bottom: 10, trailing: 5)
    section.orthogonalScrollingBehavior = .continuous
    return section
} The group layout is defined by the object, which is horizontal and has a width and height defined as 20% and 30% of the collection view's width, respectively. The group consists of a single item, which is defined above. NSCollectionLayoutGroup Section has a header defined as a . The header is placed at the top of the section and has the same width as the section, with a height of 30 points. The header's content inset by 5 points from the leading and trailing edges. NSCollectionLayoutBoundarySupplementaryItem Pinterest section A Pinterest-style layout is a type of grid-based user interface design that arranges content into a series of evenly spaced columns, with variable-sized cells that contain images. The layout is commonly used in applications like photo sharing and social media platforms. The Pinterest-style layout gives the layout a more organic, less structured feel than traditional grid-based designs, and can help to break up the monotony of a page filled with equally sized cells. Сells in this section are presented in different ratios. So, models for that cells have to conform to the protocol that defines a single requirement, the property, which is a value. Ratioable ratio CGFloat protocol Ratioable {
    var ratio: CGFloat { get }
} An aspect ratio is the proportional relationship between the width and height of an object. The implementation of this section is slightly more complicated than the previous ones. Therefore, I will create a separate class for it. PinterestLayoutSection The private properties inside of this class are: private let numberOfColumns: Int
private let itemRatios: [Ratioable]
private let spacing: CGFloat
private let contentWidth: CGFloat In order to correctly calculate the size of the section, we must pass array of elements that stores the ratio for each future cell. Also we need to have a certain number of columns and full content width. [Ratioable] For ease of understanding the code, let's add computed and lazy properties. private var padding: CGFloat {
    spacing / 2
}
    
// 1
private var insets: NSDirectionalEdgeInsets {
    .init(
        top: padding, 
        leading: padding, 
        bottom: padding, 
        trailing: padding
    )
}

// 2
private lazy var frames: [CGRect] = {
    calculateFrames()
}()
    
// 3
private lazy var sectionHeight: CGFloat = {
    (frames
        .map(\.maxY)
        .max() ?? 0
    ) + insets.bottom
}()
    
// 4
private lazy var customLayoutGroup: NSCollectionLayoutGroup = {
    let layoutSize = NSCollectionLayoutSize(
        widthDimension: .fractionalWidth(1.0),
        heightDimension: .absolute(sectionHeight)
    )
    return NSCollectionLayoutGroup.custom(layoutSize: layoutSize) { _ in
        self.frames.map { .init(frame: $0) }
    }
}() Padding around cells equal to the distance between cells. The property is a lazy property that calculates the frames for each item in the section. frames The calculates the height of the entire section based on the maximum sectionHeight y-coordinate of all the items. The is a lazy property that calculates the layout group for the section. It specifies the size of the section and returns an array of layout items based on the calculated frames. The layout group is created using the method. customLayoutGroup NSCollectionLayoutGroup.custom The last but not the least. We need to define method. calculateFrames private func calculateFrames() -> [CGRect] {
    var contentHeight: CGFloat = 0
        
    // 1
    let columnWidth = (contentWidth - insets.leading - insets.trailing) / 
                        CGFloat(numberOfColumns)
        
    // 2
    let xOffset = (0..<numberOfColumns).map { CGFloat($0) * columnWidth }
    var currentColumn = 0
    var yOffset: [CGFloat] = .init(repeating: 0, count: numberOfColumns)
        
    // Total number of frames
    var frames = [CGRect]()
        
    // 3
    for index in 0..<itemRatios.count {
        let aspectRatio = itemRatios[index]
            
        // Сalculate the frame.
        let frame = CGRect(
            x: xOffset[currentColumn],
            y: yOffset[currentColumn],
            width: columnWidth,
            height: columnWidth / aspectRatio.ratio
        )
        // Total frame inset between cells and along edges
        .insetBy(dx: padding, dy: padding)
        // Additional top and left offset to account for padding
        .offsetBy(dx: 0, dy: insets.leading)
        // 4
        .setHeight(ratio: aspectRatio.ratio)
            
        frames.append(frame)
        
        // Сalculate the height
        let columnLowestPoint = frame.maxY
        contentHeight = max(contentHeight, columnLowestPoint)
        yOffset[currentColumn] = columnLowestPoint
        // 5
        currentColumn = yOffset.indexOfMinElement ?? 0
    }
    return frames
} The is responsible for calculating the frames for each item. First, the width of each column is calculated by subtracting the margin from the total width and dividing it by the number of columns. calculateFrames Sets up variables to store the x-coordinate offset for each column, the y-coordinate offset for each column, and an array of frames. The function uses a loop to iterate through the array, calculate the frame for each item based on its aspect ratio, and append it to the array. itemRatios frames The method updates the height to keep the correct aspect ratio. Use extension for it: private extension CGRect {
    func setHeight(ratio: CGFloat) -> CGRect {
        .init(x: minX, y: minY, width: width, height: width / ratio)
    }
} Adding the next element to the minimum height column. We can move sequentially, but then there is a chance that some columns will be much longer than others. For convenience, add the extension for . The computable property helps to find the index of the first minimum element in an array: Array private extension Array where Element: Comparable {
    var indexOfMinElement: Int? {
        guard count > 0 else { return nil }
        var min = first
        var index = 0
        indices.forEach { i in
            let currentItem = self[i]
            if let minumum = min, currentItem < minumum {
                min = currentItem
                index = i
            }
        }
        return index
    }
} The final step In order to connect all the sections together into one layout, we will create another class. . CustomCompositionalLayout final class CustomCompositionalLayout {
    static func layout(
        ratios: [Ratioable], 
        contentWidth: CGFloat
    ) -> UICollectionViewCompositionalLayout {
        .init { sectionIndex, enviroment in
            guard let section = Section(rawValue: sectionIndex)
            else { return nil }
            switch section {
            case .carousel :
                return carouselBannerSection()
            case .widget :
                return widgetBannerSection()
            case .pinterest:
                return pinterestSection(ratios: ratios, contentWidth: contentWidth)
            }
        }
    }
 } It has a static function named that takes in two parameters, and . layout ratios contentWidth Don't forget to add already implemented methods to this class. The sections that can be returned are: for the case carouselBannerSection .carousel for the case widgetBannerSection .widget for the case pinterestSection .pinterest The returned value is a object that has different sections depending on the value of . UICollectionViewCompositionalLayout sectionIndex Conclusion This example of screen layout is a unique and visually appealing way to display content in a collection view. It is achieved through the use of the and the custom aspect ratios of each item in the collection. UICollectionViewCompositionalLayout Implementing this layout can greatly enhance the user experience and bring a fresh and dynamic look to your app. With its ability to handle varying aspect ratios and adjust content dynamically, the layout offers a versatile and practical solution for displaying content in a collection view. Overall, the layout with Pinterest-style section is a valuable addition to any iOS developer's toolkit and can add a touch of creativity and design to your next app project. This article was inspired by . UICollectionView Custom Layout Tutorial: Pinterest The full implementation with network layer by MVVM pattern you can find on my . Github Feel free to put stars here and on github :)

Implementing 'UICollectionView Compositional' Layout with Pinterest Section 

Most people I know use QWERTY. Many people have never heard about other keyboard layouts. How come QWERTY became the most popular keyboard, despite the fact that it might be not the most comfortable to use? QWERTY layout was designed by Christopher Sholes, one of the first inventors of typewriters in the US. He obviously needed some layout for his typewriter, and the first thing he came up with was placing letters in the : alphabetical order This keyboard was modified by Sholes and the typewriter was sold to the company E. Remington and Sons, where engineers finalised this keyboard and created modern QWERTY. The “DFGH” part shows us its inheritance from the initial alphabetical order. Even though there is a theory that QWERTY was designed to be slow to prevent internal clashing of typebars, but it doesn’t seem to be true as some very common bigrams as TH and ER are placed very close together and typed with different fingers, thus can be typed very quickly. There are also a lot of regional variations that make QWERTY more comfortable to use and where some letters are swapped or added: However, Sholes' typewriter was not the only typewriter to be invented. The 19th century was very fruitful in this regard. For example, Reverend Rasmus Malling-Hansen invented the in Denmark in 1865. Hansen Writing Ball This typewriter might look peculiar, but some people even said that it was more convenient for typing than flat keyboards. Interestingly, this typewriter was used by Friedrich Nietzsche, german philosopher, when he started having problems with his sight, but unfortunately his typewriter was damaged during transportation and he didn’t enjoy his experience. Another example of a newborn typewriter is the Blickensderfer Typewriter. It was invented in 1891 by George Canfield Blickensderfer in the US, and it was portable and full-keyboard typewriter. It contained only 250 parts, compared to the 2500 parts of a standard typewriter, which made these typewrites cheaper and more accessible. The Blickensderfer Typewriter also had a new keyboard layout. It was designed after careful analysis of the English language. It minimized redundant hand movement and increased efficiency. The most popular English letters (DHIATENSOR) are contained together on the lowest row. Unfortunately, Blickensderfer Typewriters didn’t survive the first World War and the death of its creator. These typewriters were eventually sold to E. Remington and Sons. Remington attempted to introduce a modified Blickensderfer 5 to the market, but eventually, the model was discontinued. keyboard layout can be called the successor of the Blickensderfer Typewriter’s layout, and here’s why. Dvorak This layout was designed by August Dvorak, an American professor who studied psychology of typewriting and even wrote a book about it (“Typewriting Behavior”). August and his brother-in-law William Dealey designed a new layout because they believed it to be more ergonomic and that it is faster in typing than QWERTY and patented it in 1936. If you look at this layout, you will notice that the middle row contains almost the same letters as the last row of the Blickensderfer Typewriter. The difference is that vowels and the most used symbol characters are on the left of the Dvorak layout (with the vowels on the home row), while the most used consonants are on the right. Even though Dvorak is famous as a “faster” layout, can’t be certainly acknowledged as a layout that increases speed of typing. For many years the world record holder in fast typing was Barbara Blackburn, who used Dvorak, which was been using as a proof of advantages of dvorak. But this record was unofficially beaten by Sean Wrona, who uses QWERTY. As he himself states, he could probably type faster with Dvorak, but switching to a new keyboard takes a lot of time and effort. Some people also state that Dvorak is just more comfortable for using, especially people with tunnel syndromes. There is no proper medical research on this subject, so I encourage you to investigate this side of using different keyboard layouts. As August Dvorak was thinking a lot about typewriting, he was also considering accessibility much earlier than it became a popular subject as it is today, and designed keyboard layouts for people who mostly use only one hand to type. Left-handed and right-handed dvorak layouts are available on the most operating systems as well as dvorak for two hands. Another interesting variation of dvorak is programmer dvorak, that was invented in the 2000s by Roland Kaufmann. Unlike left and right handed dvorak you can’t use it by default, you have to . install it first Letters remained in the same places, but numbers, brackets, and special symbols changed their positions; now it is easier to type brackets than numbers, as developers use various brackets much more often. The order of numbers is also interesting, as they are divided into odd and even. Another popular keyboard layout is . It was designed by and named after Shai Coleman in 2006. Colemak Coleman is a developer and he decided to design a keyboard that is easier to switch from QWERTY but that still increases typing efficiency. Hotkeys was also considered in the process of design, so the most popular ones remained in the same places. Another interesting thing is that this layout doesn’t have caps lock button, and has a second backspace instead as it is used much more often. Even though support of the most popular alternative keyboard layouts is good, using non-standard layouts still causes some problems and inconveniences. I personally use dvorak, and using hotkeys is not so easy for me as letters like “v”, “c”, “i” are spread all over keyboard. Using default vim keys is also difficult for the same reason. But the main problem for me is using hotkeys on web applications, as online photo editors or Jira. Most web apps, if they are designed for using custom hotkeys, use property, which represents a physical key on the keyboard instead of one that is actually typed. In this case, no matter which layout you use, you need to press buttons according to the QWERTY layout, which can be quite confusing and can cause unwanted actions to happen. KeyboardEvent.code That’s why was created. With method you can receive a promise with a map-like object with functions for retrieving the strings associated with specific physical keys. Keyboard API getlayoutmap() This api is used by , it can instantly detect your layout, so you can use hotkeys properly. vscode online editor But there are some pitfalls as well. The main is that support is : not good enough And it’s not only because browsers didn’t have time to implement this API (which is still experimental), but also because Keyboard API is considered harmful as it helps identifying users and can be used for . So, if you open vscode online in Safari, you will see, that it no longer detects your layout by default. But you can still work with it. fingerprinting Even without Keyboard API you can detect the current layout, even though it is slightly more difficult and requires more boilerplate (and also this is why the question is keyboard api “bad” because it exposes this information might be controversial). As I said before, there’s a keyboard property and also there’s that shows which symbol was typed. Nothing is stopping you from writing a dictionary to distinguish which layout is used. VS Code also does that as a fallback: KeyboardEvent.code KeyboardEvent.key And as soon as you start typing in vs code in Safari, it also detects your layout properly. In many aspects, keyboard layouts are not yet sufficiently studied. There’s no guarantee that any of existing or future layouts will improve your speed of typing or reduce your pain, but there are many people who were happy to try. This is why I find important to support accessibility for different users and make their life easier when possible. I encourage you to test your web applications with different layouts if your interface involves using hotkeys, your users will be grateful for this.

Keyboard Layouts and Their Place in the Web

Authors:
(1) Omid Davoodi, Carleton University, School of Computer Science;
(2) Shayan Mohammadizadehsamakosh, Sharif University of Technology, Department of Computer Engineering;
(3) Majid Komeili, Carleton University, School of Computer Science. Table of Links Abstract and Intro Background Information Methodology Prototype Interpretability Prototype-query Similarity Interpretability of the Decision-Making Process The Effects of Low Prototype Counts Discussions Prototype-query Similarity Our second set of experiments has the goal of finding out whether the regions activated by a prototype contain the same concept as the prototype itself. Prototype classifiers, in general, use the closest prototype to a query in their operation. Part-prototype classifiers follow the same idea by finding the closest prototype patch to another patch in the input image. For this to be interpretable, the notion of closeness used by the method should match that of a human. Otherwise, the explanation itself will seem nonsensical. Figure 5 shows examples of both good and bad similarity between the query patch and the prototype. As before, the first experiment was purely comparative. Each fine-grained task consisted of two pairs of images. Each pair consisted of a prototype and its activation on a query image. The prototypes picked were the most important prototypes when trying to classify an image. The idea was to avoid prototypes that were not instrumental in the final decision as they were more likely to not be present in the query image itself. The annotators were then told to select the prototype/activation pair that were conceptually more similar to each other. Figure 6 shows examples of this task where annotators are expected to select pair-2 because the corresponding images are more similar than the pair-1 images. This works well for the part-prototype classification methods as they all have an explanation generation procedure that utilizes their prototypes. On the other hand, ACE is not a classifier. It is an unsupervised concept learning method. Nevertheless, we thought that ACE by itself also had a notion of similarity baked into the method. It picks multiple patches from potentially different images to represent a concept. The assumption is that these patches are similar because they share that concept. Here, we decided to simply include two patches from the same concept in the pairs that represented ACE. The annotators were presented with batches of 10 fine-grained tasks. Like before, 2 out of those 10 tasks contained validation data. Also similar to previous experiments, annotators had to obtain qualification by completing 7 tasks perfectly before being allowed to work on the main experiment. The experiment was repeated 3 times and the results were aggregated. The instructions shown to the annotators are shown in Figure 6. As with prototype interpretability experiments, we also devised a more absolute version of the similarity experiment by adding the options "Both" and "None" to the same experimental layout. The instructions for this other experiment were as follows: • Each set contains two pairs of images. In each one, select the pair of images where the marked regions in those images are conceptually closer to each other than the other pair. • For example if in pair 1, the marked regions are conceptually very different (for example, one is of a face and the other is of the paws of a cat), do not select that pair. On the other hand, if in pair 2, the marked regions are visually and conceptually very similar, select pair 2. • If both pairs have similar regions, select Both. If none of the pairs has similar regions, select None. In total, 1156 pairs were compared and annotated by humans for the comparative study of prototype-query similarity. Table 5 shows the percentage each method was chosen against others. As can be seen, TesNet were chosen 71.88% of times when compared to other methods. At the second place was ProtoPNet with 64.47% preference. This shows that apart from TesNet, the other methods show comparatively worse prototype-query similarity compared to ProtoPNet itself. This has an interesting implication for the interpretability of these methods compared to the baseline. Table 6 shows the results of the same experiments but on a method-by-method basis. Each element of the table shows the results of the pairwise comparison between the two methods, with the method shown in the first column being the one selected out of the two. For example, the intersection between the row "ACE" and the column "ProtoPool" shows the percentage of times (24.17%) ACE was chosen against ProtoPool in the experiments. While there is more variation when looked at with this much detail, the general trends hold true. For the absolute experiments, 1984 pairs were compared and annotated by humans in total. Table 7 shows the percentage of times each method’s prototypes and query sample activations were seen to be close conceptually. While the overall rankings seem to have mostly remained the same, the lower overall percentages show that none of these methods is doing well in this regard. The best results, TesNet at 42.98% and ProtoPNet at 40.41% are still quite low. This is in agreement with the results previously reported in[12], [14]. Finally, Table 8 shows the results of the same experiments but on a method-by-method basis. Each row shows the percentage of times a method (shown on the first column) was selected either solely or as part of the "Both" option when paired with another method shown on the top row. Note that the sum of mirrored cells does not necessarily add up to 100% due to the existence of "Both" and "None" options. The consistently low similarity rates across different methods point to a general failure of all models in achieving a good similarity between the activated regions of the query samples and the prototypes. This paper is available on arxiv under CC 4.0 license. Authors: (1) Omid Davoodi, Carleton University, School of Computer Science; (2) Shayan Mohammadizadehsamakosh, Sharif University of Technology, Department of Computer Engineering; (3) Majid Komeili, Carleton University, School of Computer Science. Authors: Authors: (1) Omid Davoodi, Carleton University, School of Computer Science; (2) Shayan Mohammadizadehsamakosh, Sharif University of Technology, Department of Computer Engineering; (3) Majid Komeili, Carleton University, School of Computer Science. Table of Links Abstract and Intro Abstract and Intro Background Information Background Information Methodology Methodology Prototype Interpretability Prototype Interpretability Prototype-query Similarity Prototype-query Similarity Interpretability of the Decision-Making Process Interpretability of the Decision-Making Process The Effects of Low Prototype Counts The Effects of Low Prototype Counts Discussions Discussions Prototype-query Similarity Our second set of experiments has the goal of finding out whether the regions activated by a prototype contain the same concept as the prototype itself. Prototype classifiers, in general, use the closest prototype to a query in their operation. Part-prototype classifiers follow the same idea by finding the closest prototype patch to another patch in the input image. For this to be interpretable, the notion of closeness used by the method should match that of a human. Otherwise, the explanation itself will seem nonsensical. Figure 5 shows examples of both good and bad similarity between the query patch and the prototype. As before, the first experiment was purely comparative. Each fine-grained task consisted of two pairs of images. Each pair consisted of a prototype and its activation on a query image. The prototypes picked were the most important prototypes when trying to classify an image. The idea was to avoid prototypes that were not instrumental in the final decision as they were more likely to not be present in the query image itself. The annotators were then told to select the prototype/activation pair that were conceptually more similar to each other. Figure 6 shows examples of this task where annotators are expected to select pair-2 because the corresponding images are more similar than the pair-1 images. This works well for the part-prototype classification methods as they all have an explanation generation procedure that utilizes their prototypes. On the other hand, ACE is not a classifier. It is an unsupervised concept learning method. Nevertheless, we thought that ACE by itself also had a notion of similarity baked into the method. It picks multiple patches from potentially different images to represent a concept. The assumption is that these patches are similar because they share that concept. Here, we decided to simply include two patches from the same concept in the pairs that represented ACE. The annotators were presented with batches of 10 fine-grained tasks. Like before, 2 out of those 10 tasks contained validation data. Also similar to previous experiments, annotators had to obtain qualification by completing 7 tasks perfectly before being allowed to work on the main experiment. The experiment was repeated 3 times and the results were aggregated. The instructions shown to the annotators are shown in Figure 6. As with prototype interpretability experiments, we also devised a more absolute version of the similarity experiment by adding the options "Both" and "None" to the same experimental layout. The instructions for this other experiment were as follows: • Each set contains two pairs of images. In each one, select the pair of images where the marked regions in those images are conceptually closer to each other than the other pair. • For example if in pair 1, the marked regions are conceptually very different (for example, one is of a face and the other is of the paws of a cat), do not select that pair. On the other hand, if in pair 2, the marked regions are visually and conceptually very similar, select pair 2. • If both pairs have similar regions, select Both. If none of the pairs has similar regions, select None. In total, 1156 pairs were compared and annotated by humans for the comparative study of prototype-query similarity. Table 5 shows the percentage each method was chosen against others. As can be seen, TesNet were chosen 71.88% of times when compared to other methods. At the second place was ProtoPNet with 64.47% preference. This shows that apart from TesNet, the other methods show comparatively worse prototype-query similarity compared to ProtoPNet itself. This has an interesting implication for the interpretability of these methods compared to the baseline. Table 6 shows the results of the same experiments but on a method-by-method basis. Each element of the table shows the results of the pairwise comparison between the two methods, with the method shown in the first column being the one selected out of the two. For example, the intersection between the row "ACE" and the column "ProtoPool" shows the percentage of times (24.17%) ACE was chosen against ProtoPool in the experiments. While there is more variation when looked at with this much detail, the general trends hold true. For the absolute experiments, 1984 pairs were compared and annotated by humans in total. Table 7 shows the percentage of times each method’s prototypes and query sample activations were seen to be close conceptually. While the overall rankings seem to have mostly remained the same, the lower overall percentages show that none of these methods is doing well in this regard. The best results, TesNet at 42.98% and ProtoPNet at 40.41% are still quite low. This is in agreement with the results previously reported in[12], [14]. Finally, Table 8 shows the results of the same experiments but on a method-by-method basis. Each row shows the percentage of times a method (shown on the first column) was selected either solely or as part of the "Both" option when paired with another method shown on the top row. Note that the sum of mirrored cells does not necessarily add up to 100% due to the existence of "Both" and "None" options. The consistently low similarity rates across different methods point to a general failure of all models in achieving a good similarity between the activated regions of the query samples and the prototypes. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

Analysis of Prototype-Query Similarity Rankings

Authors:
(1) Omid Davoodi, Carleton University, School of Computer Science;
(2) Shayan Mohammadizadehsamakosh, Sharif University of Technology, Department of Computer Engineering;
(3) Majid Komeili, Carleton University, School of Computer Science. Table of Links Abstract and Intro Background Information Methodology Prototype Interpretability Prototype-query Similarity Interpretability of the Decision-Making Process The Effects of Low Prototype Counts Discussions Prototype Interpretability Our first set of experiments had the goal of finding out the interpretability of the prototypes created by each method. Many part prototype methods claim that their prototypes are intrinsically interpretable. In that case, humans should be able to understand the concept that is encoded within those prototypes. If a prototype represents a large area of an image without any coherent concept understandable to humans, it is not an interpretable prototype. In the first experiment, each person was shown a pair of prototypes (concept images in the case of ACE) on the same dataset coming from different methods. The annotators had to choose the prototype they found more interpretable out of the two. Every person had to complete 10 such pairs each time. Out of those 10, 2 were validation pairs handpicked by us to ensure answer quality. An example of such a pair and the instructions given to each person are show in Figure 4. Only people who had finished a qualification task consisting of 7 such pairs with perfect scores were allowed into the main study. Moreover, each 10-pair set of query samples was given to three different people to gauge overall agreement and find individuals who might have chosen randomly. Additionally, this experiment was repeated 3 times and the results were aggregated. This experiment was a purely comparative study between different methods. This ensured that people had a frame of reference when deciding which method worked better, and this is a common practice in many studies of subjective nature. But they are not without problems. One of the more important problems with this experiment was that it could not answer whether the prototypes from these methods were interpretable or not. It could only answer whether the prototypes of a particular method were more interpretable on average than the ones from another. To remedy this, we conducted another set of experiments. In the new absolute experiments the annotators were given the option to also choose "Both" and "None" if they thought that both or none of the images in the pair were interpretable. The reason we did not simply show them a single image asking for interpretability was to keep the layout of the experiments very similar. This not only simplified the logistics of creating query samples for the new experiment, but also gave us the opportunity to see whether the rankings of the methods seen in the comparative experiments remained the same when the new options were added. The assumption was that if a very similar experiment with those options added resulted in a drastic change in the rankings, it would reveal problems in our methodology that were hidden beforehand. Instructions given to each person were as follows: • For each pair of images, pick the one with the best highlighted patch. A good patch contains relevant and identifying regions/parts of the subject, and only such regions/parts. • If both images have good or bad patches, select "Both" or "None" respectively. • Imagine that someone points to the marked region and says: "This is an image of a bird/car/lion/etc. because of this part“. How much would you agree with that statement? It is important to note that new image pairs were created for this experiment. This was again to see if a new set of data changes the rankings considerably, revealing any potential hidden problems with the statistical significance of the results. A new qualification task and a validation set were also created. The rest of the setup was almost identical to the comparative experiment. Each time, the annotator was given 10 prototype image pairs and told to pick the best option for each pair, with two out of those 10 pairs coming from the validation set. The experiment was repeated 4 times and the results were aggregated. In total, 1104 pairs were compared and annotated by humans for the comparative study. Table 1 shows the percentage of times each method was chosen against others. As can be seen, prototypes selected by TesNet were chosen 73.26% of the time when compared to prototypes selected by other methods. In the second place was ProtoTree with 63.64% preference. It is also interesting to note the relative weakness of SPARROW and Deformable ProtoPNet. Table 2 shows the results of the same experiments but on a method-by-method basis. Each element of the table shows the results of the pairwise comparison between the two methods, with the method shown in the first column being the one selected out of the two. For example, the intersection between the row "ACE" and the column "ProtoPool" shows the percentage of times (42.86%) ACE was chosen against ProtoPool in the experiments. While there is more variation when looked at with this much detail, the general trends hold true. For the absolute experiments, 1304 pairs were compared and annotated by humans in total. Table 3 shows the percentage of times each method’s prototypes were chosen in general. As the options for "Both" and "None" also existed in this experiment, the results here show the percentage of prototypes from each method that the annotators found acceptable. While the overall rankings seem to have mostly remained the same, the higher percentages overall show that while some methods might lose in the comparative study, their prototypes are still interpretable, even if a bit less so than the more successful methods. These results also show that 95.18% of the prototypes created by TesNet and 89.56% of the ones by ProtoTree are seen as interpretable. These results match our own observations, where it seems that TesNet and ProtoTree offer consistently good prototypes in all of the datasets. Like before, Table 4 shows the results of the same experiments but on a method-by-method basis. Each row shows the percentage of times a method (shown on the first column) was selected either solely or as part of the "Both" option when paired with another method shown on the top row. Note that this time, the sum of mirrored cells does not necessarily add up to 100% due to the existence of "Both" and "None" options. The results show a fine-grained consistency in prototype interpretability rates across all methods. This paper is available on arxiv under CC 4.0 license. Authors: (1) Omid Davoodi, Carleton University, School of Computer Science; (2) Shayan Mohammadizadehsamakosh, Sharif University of Technology, Department of Computer Engineering; (3) Majid Komeili, Carleton University, School of Computer Science. Authors: Authors: (1) Omid Davoodi, Carleton University, School of Computer Science; (2) Shayan Mohammadizadehsamakosh, Sharif University of Technology, Department of Computer Engineering; (3) Majid Komeili, Carleton University, School of Computer Science. Table of Links Abstract and Intro Abstract and Intro Background Information Background Information Methodology Methodology Prototype Interpretability Prototype Interpretability Prototype-query Similarity Prototype-query Similarity Interpretability of the Decision-Making Process Interpretability of the Decision-Making Process The Effects of Low Prototype Counts The Effects of Low Prototype Counts Discussions Discussions Prototype Interpretability Our first set of experiments had the goal of finding out the interpretability of the prototypes created by each method. Many part prototype methods claim that their prototypes are intrinsically interpretable. In that case, humans should be able to understand the concept that is encoded within those prototypes. If a prototype represents a large area of an image without any coherent concept understandable to humans, it is not an interpretable prototype. In the first experiment, each person was shown a pair of prototypes (concept images in the case of ACE) on the same dataset coming from different methods. The annotators had to choose the prototype they found more interpretable out of the two. Every person had to complete 10 such pairs each time. Out of those 10, 2 were validation pairs handpicked by us to ensure answer quality. An example of such a pair and the instructions given to each person are show in Figure 4. Only people who had finished a qualification task consisting of 7 such pairs with perfect scores were allowed into the main study. Moreover, each 10-pair set of query samples was given to three different people to gauge overall agreement and find individuals who might have chosen randomly. Additionally, this experiment was repeated 3 times and the results were aggregated. This experiment was a purely comparative study between different methods. This ensured that people had a frame of reference when deciding which method worked better, and this is a common practice in many studies of subjective nature. But they are not without problems. One of the more important problems with this experiment was that it could not answer whether the prototypes from these methods were interpretable or not. It could only answer whether the prototypes of a particular method were more interpretable on average than the ones from another. To remedy this, we conducted another set of experiments. In the new absolute experiments the annotators were given the option to also choose "Both" and "None" if they thought that both or none of the images in the pair were interpretable. The reason we did not simply show them a single image asking for interpretability was to keep the layout of the experiments very similar. This not only simplified the logistics of creating query samples for the new experiment, but also gave us the opportunity to see whether the rankings of the methods seen in the comparative experiments remained the same when the new options were added. The assumption was that if a very similar experiment with those options added resulted in a drastic change in the rankings, it would reveal problems in our methodology that were hidden beforehand. Instructions given to each person were as follows: • For each pair of images, pick the one with the best highlighted patch. A good patch contains relevant and identifying regions/parts of the subject, and only such regions/parts. • If both images have good or bad patches, select "Both" or "None" respectively. • Imagine that someone points to the marked region and says: "This is an image of a bird/car/lion/etc. because of this part“. How much would you agree with that statement? It is important to note that new image pairs were created for this experiment. This was again to see if a new set of data changes the rankings considerably, revealing any potential hidden problems with the statistical significance of the results. A new qualification task and a validation set were also created. The rest of the setup was almost identical to the comparative experiment. Each time, the annotator was given 10 prototype image pairs and told to pick the best option for each pair, with two out of those 10 pairs coming from the validation set. The experiment was repeated 4 times and the results were aggregated. In total, 1104 pairs were compared and annotated by humans for the comparative study. Table 1 shows the percentage of times each method was chosen against others. As can be seen, prototypes selected by TesNet were chosen 73.26% of the time when compared to prototypes selected by other methods. In the second place was ProtoTree with 63.64% preference. It is also interesting to note the relative weakness of SPARROW and Deformable ProtoPNet. Table 2 shows the results of the same experiments but on a method-by-method basis. Each element of the table shows the results of the pairwise comparison between the two methods, with the method shown in the first column being the one selected out of the two. For example, the intersection between the row "ACE" and the column "ProtoPool" shows the percentage of times (42.86%) ACE was chosen against ProtoPool in the experiments. While there is more variation when looked at with this much detail, the general trends hold true. For the absolute experiments, 1304 pairs were compared and annotated by humans in total. Table 3 shows the percentage of times each method’s prototypes were chosen in general. As the options for "Both" and "None" also existed in this experiment, the results here show the percentage of prototypes from each method that the annotators found acceptable. While the overall rankings seem to have mostly remained the same, the higher percentages overall show that while some methods might lose in the comparative study, their prototypes are still interpretable, even if a bit less so than the more successful methods. These results also show that 95.18% of the prototypes created by TesNet and 89.56% of the ones by ProtoTree are seen as interpretable. These results match our own observations, where it seems that TesNet and ProtoTree offer consistently good prototypes in all of the datasets. Like before, Table 4 shows the results of the same experiments but on a method-by-method basis. Each row shows the percentage of times a method (shown on the first column) was selected either solely or as part of the "Both" option when paired with another method shown on the top row. Note that this time, the sum of mirrored cells does not necessarily add up to 100% due to the existence of "Both" and "None" options. The results show a fine-grained consistency in prototype interpretability rates across all methods. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

Evaluating Prototype Interpretability

Authors:
(1) Omid Davoodi, Carleton University, School of Computer Science;
(2) Shayan Mohammadizadehsamakosh, Sharif University of Technology, Department of Computer Engineering;
(3) Majid Komeili, Carleton University, School of Computer Science. Table of Links Abstract and Intro Background Information Methodology Prototype Interpretability Prototype-query Similarity Interpretability of the Decision-Making Process The Effects of Low Prototype Counts Discussions ABSTRACT Part-prototype networks have recently become methods of interest as an interpretable alternative to many of the current black-box image classifiers. However, the interpretability of these methods from the perspective of human users has not been sufficiently explored. In this work, we have devised a framework for evaluating the interpretability of part-prototype-based models from a human perspective. The proposed framework consists of three actionable metrics and experiments. To demonstrate the usefulness of our framework, we performed an extensive set of experiments using Amazon Mechanical Turk. They not only show the capability of our framework in assessing the interpretability of various part-prototype-based models, but they also are, to the best of our knowledge, the most comprehensive work on evaluating such methods in a unified framework. Introduction As Artificial Intelligence and Machine Learning have become more ubiquitous in many parts of the society and economy, the need for transparency, fairness, and trust increases. Many of the state-of-the-art methods and algorithms are black boxes where the decision-making process is opaque to humans. Interpretable and Explainable Artificial Intelligence aims to address this issue by offering methods that either explain the decisions of black-box models or are inherently interpretable themselves. Prototype-based classifiers are a category of inherently interpretable methods that use prototypical examples to make their decisions. It is assumed that as long as the prototypes themselves are understandable by a human, the decision itself is interpretable[1]. Prototype-based classifiers are not new inventions. Many existed long before the need for interpretability became so urgent[2–6]. In recent years, newer methods have been proposed that combine the power and expressablility of neural networks with the decision-making process of a prototype based classifier to create prototypical neural nets[7], [8], reaching results competitive with the state of the art while being inherently interpretable in the process. A newer subcategory of prototype-based classifiers is part-prototype networks. These networks, usually operating in the domain of image classification use regions of a query sample, as opposed to the entire query image, to make their decisions. ProtoPNet[9] is the first of such methods that offered fine-grained explanations for image classification while offering state-of-the-art accuracy. Figure 1 shows an example of how a part-prototype method makes its decisions. The explanations given by these methods can be very different from each other. Even when the general layout of the explanation is similar, the part-prototypes themselves can be vastly different. It is unusual to assume that they offer the same level of interpretability. Therefore, the evaluation of their interpretability is necessary. While many of these methods evaluate the performance of their models and compare them to the state of the art, few analyze the interpretability of their methods. Most of the analysis in this regard seems to be focused on automatic metrics for assessing interpretability[10]. Such automatic metrics, while useful, are not a replacement for human evaluation of interpretability. Others have worked on human-assisted debugging[11] but have not extended that to a full evaluation of method interpretability. Kim et al. offered a method for evaluating visual concepts by humans and even performed experiments on ProtoPNet and ProtoTree[12], but their evaluation suffers from a number of issues. The scale of the experiments in Kim et al. is small, with only two part-prototype methods evaluated using only a single dataset. The experimental design of that work also relies on fine-grained ratings by human annotators. This type of design can be an unreliable way of measuring human opinion when there is no consensus on what each option means[13]. It used the class label to measure the quality of the prototypes in the CUB dataset even though there was no indication that the human users were familiar with the minutiae of the distinctions between 200 classes of birds. Lastly, it used the default rectangular representation of prototypes from ProtoPNet and ProtoTree. These representations are prone to being overly broad and misleading to the human user compared to the actual activation heatmap. As a result, we propose a human-centric analysis consisting of a set of experiments to assess the interpretability of part-prototype methods. Goals The interpretability of a part-prototype system is not a well-defined concept. In this work, we focus on three properties that such systems should have in order to be interpretable. • Interpretability of the prototype itself: The concept a prototype is referring to should be recognizable and understandable to a human. Figure 2 (a) shows an example of a prototype that is not interpretable because it points to an irrelevant background region. Machine learning methods and neural networks, in particular, can make correct decisions based on feature combinations in the data that a human might not understand. In addition, the presentation of such features is very important. A prototype might refer to a very unusual concept but its presentation might lead a human to wrongfully believe that they understand the reasoning behind a decision. • The similarity of a prototype to the corresponding region in the query sample: Even if the prototype itself is easily understood by a human, its activation on the query sample might not show the same concept as the prototype. Figure 2 (b) shows an example of this problem. This is important because it shows that the structural similarity in the embedding space that the prototypes reside in is not compatible with human understanding of similarity. This is a problem that has been reported in previous literature[14]. • The interpretability of the decision-making process itself is also an important aspect of prototype-based methods. Even if the prototypes and their similarity to the activated patches of the query sample are understood by humans, the final decision might not be. For example, a model might select and use unrelated prototypes to correctly classify a sample. The main novelty of this work is a more robust framework for evaluating the interpretability of part-prototype-based networks using human annotators. Some previous methods have tried to do such evaluations based on automatic metrics[10], and some other works have worked on human-based evaluation of interpretability for other types of explainable AI methods[15], [16]. The closest work is HIVE[12] which suffers from a number of issues that are addressed in our approach. More on this will follow in the next section. Another novelty of this work is the proposal of three actionable metrics and experiments for evaluating the interpretability of part-prototype-based classifiers. We believe that if a model fails these tests, it would not be a good interpretable model. These can assist future researchers in providing evidence rather than just making assumptions about the interpretability of their approaches. Finally, our extensive set of experiments using Amazon Mechanical Turk includes comparisons of six related methods on three datasets. To the best of our knowledge, this is the most comprehensive work on evaluating the interpretability of such methods in a unified framework. This paper is available on arxiv under CC 4.0 license. Authors: (1) Omid Davoodi, Carleton University, School of Computer Science; (2) Shayan Mohammadizadehsamakosh, Sharif University of Technology, Department of Computer Engineering; (3) Majid Komeili, Carleton University, School of Computer Science. Authors: Authors: (1) Omid Davoodi, Carleton University, School of Computer Science; (2) Shayan Mohammadizadehsamakosh, Sharif University of Technology, Department of Computer Engineering; (3) Majid Komeili, Carleton University, School of Computer Science. Table of Links Abstract and Intro Abstract and Intro Background Information Background Information Methodology Methodology Prototype Interpretability Prototype Interpretability Prototype-query Similarity Prototype-query Similarity Interpretability of the Decision-Making Process Interpretability of the Decision-Making Process The Effects of Low Prototype Counts The Effects of Low Prototype Counts Discussions Discussions ABSTRACT Part-prototype networks have recently become methods of interest as an interpretable alternative to many of the current black-box image classifiers. However, the interpretability of these methods from the perspective of human users has not been sufficiently explored. In this work, we have devised a framework for evaluating the interpretability of part-prototype-based models from a human perspective. The proposed framework consists of three actionable metrics and experiments. To demonstrate the usefulness of our framework, we performed an extensive set of experiments using Amazon Mechanical Turk. They not only show the capability of our framework in assessing the interpretability of various part-prototype-based models, but they also are, to the best of our knowledge, the most comprehensive work on evaluating such methods in a unified framework. Introduction As Artificial Intelligence and Machine Learning have become more ubiquitous in many parts of the society and economy, the need for transparency, fairness, and trust increases. Many of the state-of-the-art methods and algorithms are black boxes where the decision-making process is opaque to humans. Interpretable and Explainable Artificial Intelligence aims to address this issue by offering methods that either explain the decisions of black-box models or are inherently interpretable themselves. Prototype-based classifiers are a category of inherently interpretable methods that use prototypical examples to make their decisions. It is assumed that as long as the prototypes themselves are understandable by a human, the decision itself is interpretable[1]. Prototype-based classifiers are not new inventions. Many existed long before the need for interpretability became so urgent[2–6]. In recent years, newer methods have been proposed that combine the power and expressablility of neural networks with the decision-making process of a prototype based classifier to create prototypical neural nets[7], [8], reaching results competitive with the state of the art while being inherently interpretable in the process. A newer subcategory of prototype-based classifiers is part-prototype networks. These networks, usually operating in the domain of image classification use regions of a query sample, as opposed to the entire query image, to make their decisions. ProtoPNet[9] is the first of such methods that offered fine-grained explanations for image classification while offering state-of-the-art accuracy. Figure 1 shows an example of how a part-prototype method makes its decisions. The explanations given by these methods can be very different from each other. Even when the general layout of the explanation is similar, the part-prototypes themselves can be vastly different. It is unusual to assume that they offer the same level of interpretability. Therefore, the evaluation of their interpretability is necessary. While many of these methods evaluate the performance of their models and compare them to the state of the art, few analyze the interpretability of their methods. Most of the analysis in this regard seems to be focused on automatic metrics for assessing interpretability[10]. Such automatic metrics, while useful, are not a replacement for human evaluation of interpretability. Others have worked on human-assisted debugging[11] but have not extended that to a full evaluation of method interpretability. Kim et al. offered a method for evaluating visual concepts by humans and even performed experiments on ProtoPNet and ProtoTree[12], but their evaluation suffers from a number of issues. The scale of the experiments in Kim et al. is small, with only two part-prototype methods evaluated using only a single dataset. The experimental design of that work also relies on fine-grained ratings by human annotators. This type of design can be an unreliable way of measuring human opinion when there is no consensus on what each option means[13]. It used the class label to measure the quality of the prototypes in the CUB dataset even though there was no indication that the human users were familiar with the minutiae of the distinctions between 200 classes of birds. Lastly, it used the default rectangular representation of prototypes from ProtoPNet and ProtoTree. These representations are prone to being overly broad and misleading to the human user compared to the actual activation heatmap. As a result, we propose a human-centric analysis consisting of a set of experiments to assess the interpretability of part-prototype methods. Goals The interpretability of a part-prototype system is not a well-defined concept. In this work, we focus on three properties that such systems should have in order to be interpretable. • Interpretability of the prototype itself: The concept a prototype is referring to should be recognizable and understandable to a human. Figure 2 (a) shows an example of a prototype that is not interpretable because it points to an irrelevant background region. Machine learning methods and neural networks, in particular, can make correct decisions based on feature combinations in the data that a human might not understand. In addition, the presentation of such features is very important. A prototype might refer to a very unusual concept but its presentation might lead a human to wrongfully believe that they understand the reasoning behind a decision. • The similarity of a prototype to the corresponding region in the query sample: Even if the prototype itself is easily understood by a human, its activation on the query sample might not show the same concept as the prototype. Figure 2 (b) shows an example of this problem. This is important because it shows that the structural similarity in the embedding space that the prototypes reside in is not compatible with human understanding of similarity. This is a problem that has been reported in previous literature[14]. • The interpretability of the decision-making process itself is also an important aspect of prototype-based methods. Even if the prototypes and their similarity to the activated patches of the query sample are understood by humans, the final decision might not be. For example, a model might select and use unrelated prototypes to correctly classify a sample. The main novelty of this work is a more robust framework for evaluating the interpretability of part-prototype-based networks using human annotators. Some previous methods have tried to do such evaluations based on automatic metrics[10], and some other works have worked on human-based evaluation of interpretability for other types of explainable AI methods[15], [16]. The closest work is HIVE[12] which suffers from a number of issues that are addressed in our approach. More on this will follow in the next section. Another novelty of this work is the proposal of three actionable metrics and experiments for evaluating the interpretability of part-prototype-based classifiers. We believe that if a model fails these tests, it would not be a good interpretable model. These can assist future researchers in providing evidence rather than just making assumptions about the interpretability of their approaches. Finally, our extensive set of experiments using Amazon Mechanical Turk includes comparisons of six related methods on three datasets. To the best of our knowledge, this is the most comprehensive work on evaluating the interpretability of such methods in a unified framework. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

On the Interpretability of Part-Prototype Based Classifiers: A Human Centric Analysis

পার্ট-প্রোটোটাইপ ভিত্তিক ক্লাসিফায়ারগুলির ব্যাখ্যাযোগ্যতা: একটি মানবকেন্দ্রিক বিশ্লেষণ

Zur Interpretierbarkeit von auf Teilprototypen basierenden Klassifikatoren: Eine menschenzentrierte Analyse

Sobre la interpretabilidad de clasificadores basados en prototipos parciales: un análisis centrado en el ser humano

Sur l'interprétabilité des classificateurs basés sur des pièces-prototypes : une analyse centrée sur l'humain

पार्ट-प्रोटोटाइप आधारित क्लासिफायर की व्याख्या पर: एक मानव केंद्रित विश्लेषण

部分プロトタイプベースの分類器の解釈可能性について: 人間中心の分析

부분 프로토타입 기반 분류기의 해석 가능성: 인간 중심 분석

Sobre a interpretabilidade de classificadores baseados em protótipos de peças: uma análise centrada no ser humano

Об интерпретируемости классификаторов, основанных на прототипах деталей: человекоцентричный анализ

Parça Prototip Tabanlı Sınıflandırıcıların Yorumlanabilirliği Üzerine: İnsan Odaklı Bir Analiz

Về khả năng giải thích của các bộ phân loại dựa trên nguyên mẫu từng phần: Phân tích lấy con người làm trung tâm

基于部分原型的分类器的可解释性：以人为中心的分析

Plunging Into Data: Unraveling Time Series Patterns

I've always liked GUI, both desktop-based and browser-based, before you needed five years of training on the latter. That's the reason I loved and still love Vaadin: you can develop web UIs without writing a single line of HTML, JavaScript, and CSS. I'm still interested in the subject; a couple of years ago, I analyzed the state of JVM desktop frameworks. I also like the Rust programming language a lot. Tauri is a Rust-based framework for building desktop applications. Here's my view. Overview Build an optimized, secure, and frontend-independent application for multi-platform deployment.
-- Tauri website A Tauri app is composed of two modules: the client-side module in standard Web technologies (HTML, Javascript, and CSS) and the backend module in Rust. Tauri runs the UI in a dedicated Chrome browser instance. Users interact with the UI as usual. Tauri offers a binding between the client-side JavaScript and the backend Rust via a specific JS module, i.e, window.__TAURI__.tauri. It also offers other modules for interacting with the local system, such as the filesystem, OS, clipboard, window management, etc. Binding is based on strings. Here's the client-side code: const { invoke } = window.__TAURI__.tauri;

let greetInputEl;
let greetMsgEl;

greetMsgEl.textContent = await invoke("greet", { name: greetInputEl.value });  //1 Invoke the Tauri command named greet Here's the corresponding Rust code: #[tauri::command]                                                              //1
fn greet(name: &str) -> String {                                               //1
    format!("Hello, {}! You've been greeted from Rust!", name)
} Define a Tauri command named greet In the following sections, I'll list Tauri's good, meh, and bad points. Remember that it's my subjective opinion based on my previous experiences. The good Getting started:
Fortunately, it is becoming increasingly rare, but some technologies need to remember that before you're an expert, you're a newbie. The first section of any site should be a quick explanation of the technology, and the second a getting started. Tauri succeeds in this; I got my first Tauri app in a matter of minutes by following the Quick start guide.


Documentation:
Tauri's documentation is comprehensive, extensive (as far as my musings browsed them), and well-structured.


Great feedback loop:
I've experienced exciting technologies where the feedback loop, the time it takes to see the results of a change, makes the technology unusable. GWT, I'm looking at you. Short feedback loops contribute to a great developer experience.
In this regard, Tauri scores points. One can launch the app with a simple cargo tauri dev command. If the front end changes, Tauri reloads it. If any metadata changes, e.g., anything stored in tauri.conf.json, Tauri restarts the app. The only downside is that both behaviors lose the UI state.


Complete lifecycle management:
Tauri not only helps you develop your app but also provides the tools to debug, test, build, and distribute it. The meh At first, I wanted to create my usual showcase for desktop applications, a file renamer app. However, I soon hit an issue when I wanted to select a directory using the file browser button. First, Tauri doesn't allow the use of the regular JavaScript file-related API; Instead, it provides a more limited API. Worse, you need to explicitly configure which file system paths are available at build time, and they are part of an enumeration. I understand that security is a growing concern in modern software. Yet, I fail to understand this limitation on a desktop app, where every other app can access any directory. The bad However, Tauri's biggest problem is its design, more precisely, its separation between the front and the back end. What I love in Vaadin is its management of all things frontend, leaving you to learn the framework only. It allows your backend developers to build web apps without dealing with HTML, CSS, and JavaScript. Tauri, though a desktop framework, made precisely the opposite choice. Your developers will need to know frontend technologies. Worse, the separation reproduces the request-response model created using browser technologies to create UIs. Reminder: early desktop apps use the Observer model, which better fits user interactions. We designed apps around the request-response model only after we ported them on the web. Using this model in a desktop app is a regression, in my opinion. Conclusion Tauri has many things to like, mainly everything that revolves around the developer experience. If you or your organization uses and likes web technologies, try Tauri. However, it's a no-go for me: to create a simple desktop app, I don't want to learn how to center a div or about the flexbox layout, etc. To go further: Tauri I've always liked GUI, both desktop-based and browser-based, before you needed five years of training on the latter. That's the reason I loved and still love Vaadin : you can develop web UIs without writing a single line of HTML, JavaScript, and CSS. I'm still interested in the subject; a couple of years ago, I analyzed the state of JVM desktop frameworks . Vaadin state of JVM desktop frameworks I also like the Rust programming language a lot. Tauri is a Rust-based framework for building desktop applications. Here's my view. Overview Build an optimized, secure, and frontend-independent application for multi-platform deployment. -- Tauri website Build an optimized, secure, and frontend-independent application for multi-platform deployment. -- Tauri website Tauri website A Tauri app is composed of two modules: the client-side module in standard Web technologies (HTML, Javascript, and CSS) and the backend module in Rust. Tauri runs the UI in a dedicated Chrome browser instance. Users interact with the UI as usual. Tauri offers a binding between the client-side JavaScript and the backend Rust via a specific JS module, i.e , window.__TAURI__.tauri . It also offers other modules for interacting with the local system, such as the filesystem, OS, clipboard, window management, etc. i.e window.__TAURI__.tauri Binding is based on strings. Here's the client-side code: const { invoke } = window.__TAURI__.tauri;

let greetInputEl;
let greetMsgEl;

greetMsgEl.textContent = await invoke("greet", { name: greetInputEl.value });  //1 const { invoke } = window.__TAURI__.tauri;

let greetInputEl;
let greetMsgEl;

greetMsgEl.textContent = await invoke("greet", { name: greetInputEl.value });  //1 Invoke the Tauri command named greet Invoke the Tauri command named greet greet Here's the corresponding Rust code: #[tauri::command]                                                              //1
fn greet(name: &str) -> String {                                               //1
    format!("Hello, {}! You've been greeted from Rust!", name)
} #[tauri::command]                                                              //1
fn greet(name: &str) -> String {                                               //1
    format!("Hello, {}! You've been greeted from Rust!", name)
} Define a Tauri command named greet Define a Tauri command named greet greet In the following sections, I'll list Tauri's good, meh, and bad points. Remember that it's my subjective opinion based on my previous experiences. The good Getting started:
Fortunately, it is becoming increasingly rare, but some technologies need to remember that before you're an expert, you're a newbie. The first section of any site should be a quick explanation of the technology, and the second a getting started. Tauri succeeds in this; I got my first Tauri app in a matter of minutes by following the Quick start guide. Documentation:
Tauri's documentation is comprehensive, extensive (as far as my musings browsed them), and well-structured. Great feedback loop:
I've experienced exciting technologies where the feedback loop, the time it takes to see the results of a change, makes the technology unusable. GWT, I'm looking at you. Short feedback loops contribute to a great developer experience.
In this regard, Tauri scores points. One can launch the app with a simple cargo tauri dev command. If the front end changes, Tauri reloads it. If any metadata changes, e.g., anything stored in tauri.conf.json, Tauri restarts the app. The only downside is that both behaviors lose the UI state. Complete lifecycle management:
Tauri not only helps you develop your app but also provides the tools to debug, test, build, and distribute it. Getting started: Fortunately, it is becoming increasingly rare, but some technologies need to remember that before you're an expert, you're a newbie. The first section of any site should be a quick explanation of the technology, and the second a getting started. Tauri succeeds in this; I got my first Tauri app in a matter of minutes by following the Quick start guide. Getting started: Fortunately, it is becoming increasingly rare, but some technologies need to remember that before you're an expert, you're a newbie. The first section of any site should be a quick explanation of the technology, and the second a getting started. Tauri succeeds in this; I got my first Tauri app in a matter of minutes by following the Quick start guide. Quick start Documentation: Tauri's documentation is comprehensive, extensive (as far as my musings browsed them), and well-structured. Documentation: Tauri's documentation is comprehensive, extensive (as far as my musings browsed them), and well-structured. Great feedback loop: I've experienced exciting technologies where the feedback loop, the time it takes to see the results of a change, makes the technology unusable. GWT, I'm looking at you. Short feedback loops contribute to a great developer experience. In this regard, Tauri scores points. One can launch the app with a simple cargo tauri dev command. If the front end changes, Tauri reloads it. If any metadata changes, e.g., anything stored in tauri.conf.json, Tauri restarts the app. The only downside is that both behaviors lose the UI state. Great feedback loop: I've experienced exciting technologies where the feedback loop, the time it takes to see the results of a change, makes the technology unusable. GWT , I'm looking at you. Short feedback loops contribute to a great developer experience. GWT In this regard, Tauri scores points. One can launch the app with a simple cargo tauri dev command. If the front end changes, Tauri reloads it. If any metadata changes, e.g. , anything stored in tauri.conf.json , Tauri restarts the app. The only downside is that both behaviors lose the UI state. cargo tauri dev e.g. tauri.conf.json Complete lifecycle management: Tauri not only helps you develop your app but also provides the tools to debug, test, build, and distribute it. Complete lifecycle management: Tauri not only helps you develop your app but also provides the tools to debug , test , build , and distribute it. debug test build distribute The meh At first, I wanted to create my usual showcase for desktop applications, a file renamer app . However, I soon hit an issue when I wanted to select a directory using the file browser button. First, Tauri doesn't allow the use of the regular JavaScript file-related API; Instead, it provides a more limited API. Worse, you need to explicitly configure which file system paths are available at build time, and they are part of an enumeration. file renamer app I understand that security is a growing concern in modern software. Yet, I fail to understand this limitation on a desktop app, where every other app can access any directory. The bad However, Tauri's biggest problem is its design, more precisely, its separation between the front and the back end. What I love in Vaadin is its management of all things frontend, leaving you to learn the framework only. It allows your backend developers to build web apps without dealing with HTML, CSS, and JavaScript. Tauri, though a desktop framework, made precisely the opposite choice. Your developers will need to know frontend technologies. Worse, the separation reproduces the request-response model created using browser technologies to create UIs. Reminder: early desktop apps use the Observer model , which better fits user interactions. We designed apps around the request-response model only after we ported them on the web. Using this model in a desktop app is a regression, in my opinion. Observer model Conclusion Tauri has many things to like, mainly everything that revolves around the developer experience. If you or your organization uses and likes web technologies, try Tauri. However, it's a no-go for me: to create a simple desktop app, I don't want to learn how to center a div or about the flexbox layout, etc. div To go further: To go further: Tauri Tauri Tauri

Stories, News & Mentions about LAIOUT

Laiout’s Stories on HackerNoon