Tag: apps

Build Great Apps: Designer and Developer Collaboration Just Got Easier

(This is a sponsored post.)

We’re going to go over details on how designer ↔️ developer collaboration in AWS Amplify Studio can make app building easier, but let’s cover one of those things right at the top here.

Say your designer (or you!) like to work in Figma, the predominant tool in UI design these days. The whole design system is there, from colors and fonts, to atomic components like buttons and forms, to larger layout components like Cards and Collections. The designs in Figma evolve, and when they do, it’s a developer’s job to port the changes over to the site. What if… that didn’t need to be manual work? With AWS Amplify you can now suck over those updated Figma designs directly without any work other than reviewing and accepting the changes. That’s some pretty magical stuff that people have only theorized would be possible one day with design tooling. Now it’s here.

We will get more into that in a minute, I just wanted to make sure you caught that upfront.

Setting the Stage

Designers often struggle to work with developers and vice versa, even though both are usually passionate about delivering great app experiences. If you’re a designer, if you’ve ever had to hand off your visual wonder to a developer, then you know the dread that sometimes follows. Will your developer know how to implement your design fully? Will pixels get removed? Will I be happy with the final iteration?

If you’re a developer, you may think of design implementation and iteration as a tedious and manual process. You may not feel equipped to think about design, even though you do care about delighting your customers and end-users and growing your business.

There are a lot of tools that are intended to help facilitate the handoff process. However, most don’t fully address the implementation of the design.

The AWS Amplify team recently launched AWS Amplify Studio, a new visual development environment that lets front-end developers build full-stack apps with minimal coding while integrating Amplify’s powerful backend configuration and management capabilities. Amplify Studio helps automate the design implementation process, helping designers and developers to work better together, and ensuring that designs are implemented into the final product. Let’s dive in and check out the new capabilities.

Let’s build an app

In the previous post, we outlined Amplify Studio’s functionality. Now let’s walk through how to build and deploy a web app quickly, on AWS. Amplify Studio contains backend creation and management capabilities, simplifying setup and management of app backend infrastructure, such as database tables, user authentication, and file storage, without requiring cloud expertise.

Use the visual development environment to define a data model, user authentication, and file storage without backend expertise. Amplify Studio helps you do the heavy lifting. Let’s focus on the UI and data binding.

This whole demo was done by Ali Spittel, a Senior Developer Advocate for AWS Amplify.

For demonstration’s sake, imagine it’s a home rental app.

First, let’s create a data model so that we can link data to my UI components. Then create a component with an image of the rental, a name, price, and location. 

Then, we can save and deploy.

Next, let’s go over to Figma. Amplify Studio helps developers and UX designers work better together. In addition to the significant time it takes for developers to implement designs and iterations, often, the UX designs aren’t implemented accurately, which frustrates designers and leads to a sub-optimal end-user experience. With Amplify Studio, developers can import custom UI components created by their designers from Figma, or they can use the UI component library provided by Amplify Studio, and customize them to fit their style guide. 

The Amplify team launched a Figma file called the AWS Amplify UI Kit. 

The styling correlates with the Amplify UI library, which includes primitives, components (which are combinations of the primitives), cards, and collections.

Duplicate the file as a starter then edit away!  

You can customize the components however you wish. If you’re working with a UX designer, both of you can work with the Figma project and import the UX designs into Amplify Studio.

Amplify Studio’s Figma-to-code plugin lets me import UX designs directly from Figma, which are automatically translated into clean React code that can be further customized.

To import the UX components, paste the link to the Figma file and paste it into Amplify Studio.

All of my components from my Figma file will be imported into Amplify Studio. You’re able to review the imported components in Figma and decide whether to accept or reject them, as an added quality check.  If you are importing a design iteration, this helps you to see what the design changes are before you implement them.

This process helps me save time from not having to write thousands of lines of code, since Amplify Studio autogenerates it for me. It creates human readable, credible React code. Later, if needed, you can extend this code for additional control over the components.

We can then link the UI components to data from the data model, and can add child properties like rental price, name, and location. 

We can create a collection of components, and customize the layout. Say we want to display them as a list or a grid or change the direction that it goes in, adjust spacing, and so on. We can choose the data that is displayed on my page. 

Now, let’s need to integrate this into the app. Studio gives me code snippets to use to get my components into my app. 

Run the command amplify pull, which runs some code generation from all the Figma components we pulled into Amplify Studio. Then we can use these React components like you would any other in the code base.

We’ll have an Amplify directory with information about the API, and also have a models directory with data that is created on the front end. We also have a full UI components directory, which has all of the UI components that we created in Figma and imported into Amplify Studio. 

Say we’ve installed the Amplify JavaScript libraries and React UI components. We’ll use a couple of lines of code to configure Amplify for this app. We can use the Amplify Provider component which will be at the top level. It will allow us to have the right styling for my UI components. 

In the component below, we import the CSS file, then import the rental collection. Then we can see my React code for the app. This is the code that was generated by Amplify. 

Here are the properties that we can change in the Amplify UI documentation. 

We can also add overrides to items in the generated components. 

A lot of companies have their own style guides, and that’s great! We can use Amplify Studio to details of these style guides to Figma and ultimately our entire app.

There’s a new Figma plugin you can install: AWS Amplify Theme Editor. If you want to add a custom theme to the UI, you can use the plugin for that. This happens via CSS custom properties, with JavaScript objects, or design tokens within Figma using the Amplify UI Theme Editor plugin. You can use it to change the color palette, component colors, and brand colors. 

One of the great things about Amplify Studio is it works with the tools that designers and developers use, but helps to centralize and streamline their workflow while facilitating tighter collaboration. 

Designers can be assured that their UX designs and iterations are being fully implemented. Developers can be assured that they are incorporating design implementations as a part of their CI/CD process. As developers, we can save time not needing to translate designers’ ideas and changes into code, and we can focus on building a better app experience and the end users’ needs while making sure we haven’t missed the design details. 

Once this app is ready to deploy, we can host the app with Amplify Hosting. It offers hosting for any React, Vue, or Next.js web app with built-in continuous integration and continuous deployment (CI/CD) workflows, testing, pull request previews, and custom domains. 

Amplify Studio’s frontend UI capabilities are in preview (its app backend capabilities are generally available). You can go to the sandbox to try it out.

Calls to action

CSS-Tricks

, , , , , , ,

Have Single-Page Apps Ruined the Web? (“Transitional Apps”)

A big heaping 19-minute bowl of not-too-hot, not-too-cold baby bear porridge website building from Rich Harris. I’ve certainly overheard more than my fair share of arguments about Single Page Apps (SPAs) vs Multi-Page Apps (MPAs).

Although, I will say it’s only recently that I’ve heard people put an acronym to MPA, and it feels weird. My guess is that most folks actually hold appropriately-nuanced opinions about what site-building architectures are appropriate for the sites they are building. But it’s fun to pit hardline-opinioned caricatures of developers against each other and extract the best points from each side.

The irony is that the way the industry is going, picking SPA or MPA isn’t an all-in choice. You can literally have aspects of both on one site. And while technologies, like SvelteKit and Astro, are helping it along directly, I’m sure there are lots of sites out there already doing it by virtue of being a hodgepodge of technology smushed together to make business happen over long spans of years. (I may or may not be talking about my own experience on CodePen.)

I quite like how some very newfangled stuff is awesome and worth picking up and taking advantage of, while some old stuff has really stood the test of time and is just as useful today as ever.

If you can’t get enough of the topic, Surma and Jake get into it as well.


The post Have Single-Page Apps Ruined the Web? (“Transitional Apps”) appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , ,
[Top]

Considerations for Using Markdown Writing Apps on Static Sites

If you run or have recently switched to a static site generator, you might find yourself writing a lot of Markdown. And the more you write it, the more you want the tooling experience to disappear so that the content takes focus.

I’m going to give you some options (including my favorite), but more importantly, I’ll walk though features that these apps offer that are especially relevant when choosing. Here are some key considerations for Markdown editing apps to help the words flow.

Consideration #1: Separate writing and reading modes

UX principles tell us that modes are problematic. But perhaps there is an exception for text editing software. From vi(m) to Google Docs, separate modes for writing and reading seem to appeal to writers. Similarly, many Markdown editors have separate modes or views for writing, editing and reading.

I happen to like Markdown editors that provide a side-by-side or paned design where I can see both at once. Writing Markdown is not the same as writing code. What it looks like matters, and having a preview can give you a feel for that. It’s kind of like static site generators that auto-refresh so that you can see your changes as you make them.

Having both edit and preview mode active at once can help you feel more connected to the finished product.

In contrast, I’m not a fan of the one-mode-to-rule-them-all design where Markdown formatting automatically converts to styled text, hiding the formatted code (implemented in some form by Dropbox Paper, Typora, Ulysses, and Bear). I can’t stand the work of futzing with the app to change a heading level, for example. Do I click it, double-click, triple-click? What if I’m just using the keyboard?

It’s not so much that these features aren’t useful, it’s that they break my flow.

I want to see all the Markdown that I’ve written, even if the end user won’t. That’s one thing that I do want a Markdown editor to borrow from code editors.

Consideration #2: Good themes

Some Markdown editors allow full customization of editor themes, while others ship with nice ones out of the box. Regardless, I think a good editor should have just the right amount of styling to differentiate plain text from formatted text, but not so much that it distracts you from being able to read it and focus on the content. Even with the preview pane open, I typically spend most of my time looking at the editing view.

Different colors for each style

Since most of the text in the editor isn’t going to be rendered as it would in the browser, it’s nice to quickly see which text you’ve formatted using Markdown. This helps you determine, for example, whether a URL is actually written out in the text or is used inside a hyperlink. So, I like to have a different color for each Markdown style (headings, links, bold, italic, quotes, images, code, bullets, etc.)

Colors tell you which text has Markdown formatting applied.

Apply bold and italics styles too

I prefer to use asterisks for Markdown formatting everywhere I’m able to (e.g., bold, italics, and unordered lists), so I find it helpful to have extra styling beyond color to distinguish bold, italic, and bold+italic. When skimming it can be hard to differentiate between **this is important** and *this is important*, whereas **this is important** and *this is important* are easier to separate. It also helps me see if I’ve accidentally mismatched asterisks (e.g., **is this important?*).

Different font sizes for each heading level

This might be a bit controversial and may split the audience. Code editors don’t show different font sizes within a file. Colors and styles, sure, but not sizes. But, for me, it helps.

When writing, hierarchy is the key to organization. With different font sizes for each heading, you can see the outline of whatever you’re writing just by skimming through it.

Seeing the headings in different font sizes is a subtle way to help you visualize the structure. This is especially helpful for long content.

Shortcuts and smart keyboard behaviors

I expect all the standard shortcuts that work in a text editor to work. CTRL/CMD + B for bold, I for italic, etc., as well as some that are nice-to-have when writing articles, in particular CTRL/CMD + (number) for headings. CTRL/CMD + 1 for H1, etc.

Making something into a heading should be a simple shortcut.

But there are also some keyboard behaviors I like that are borrowed from code editors. For example, if I select some text and press [ or ( it won’t overwrite that text, but, instead, enclose it with the opening and closing character. Same for using text formatting characters like *, `, and _.

A good Markdown editor won’t overwrite your text when you select it and press a valid Markdown formatting character.

I also rely on keyboard shortcuts to create links and images. Even after more than five years of writing Markdown on a regular basis, I still sometimes forget whether the brackets or parentheses comes first. So, I really like having a handy shortcut to insert them correctly.

Even better, in some editors, if you have a URL in your clipboard and you select text then use a keyboard shortcut to make it into a link, it will insert the URL in the hyperlink field. This has really sped up my workflow.

When I have a URL in the clipboard and use the create link shortcut, it assumes that’s what I want to link to. Handy!

Bonus feature: Copy to HTML

The editor that I use most often has a one-click “Copy HTML” feature (with keyboard shortcut) that takes all of the Markdown I’ve written and copies the HTML to the clipboard. This can be very convenient when using an online editor (e.g., WordPress) that has a code/source option.

Easy peasy!

Consideration #3: Stand-alone editor vs. CMS/IDE plugin

I know that a lot of people who work with static site generators love their IDEs and may even jump back and forth between code and Markdown in a single day. I often do. So I can see why using a familiar IDE would be more attractive than having a separate app for Markdown.

But when I’m sitting down to write a page in Markdown or an article, where I’m focusing on the text itself, I prefer a separate app.

I’m not fanatical about using standalone Markdown editors over IDE editor or plugins; I use one occasionally for complex find-and-replace tasks and other edits. As long as it offers the benefits listed above, I wouldn’t try to talk anyone out of it.

Here are a few reasons why a standalone app might work better for writing:

  • Cleaner interface. I’m not someone who needs “Zen mode” in my writing app, but I do like to have as few panels open as possible when I’m writing, which typically requires turning a lot of things off in an IDE.
  • Performance. Most Markdown tools just feel lighter to me. They are certainly less complex and do less stuff, so they should be faster. I don’t ever want to feel like my writing app is exerting any effort. It should launch fast and respond instantly, always.
  • Availability. I just haven’t found a Markdown editor in an IDE that I really like. Perhaps there is one out there; I just don’t have time to try them all. But I like most standalone Markdown editors that I’ve used, and I can’t say the same for what I’ve tried in IDE-land.
  • Mental shift. When I open my IDE, I’m thinking about writing code, but when I open my Markdown editor, I’m thinking about writing words. I like that it gets me into the right mindset.
That’s a few too many choices.

My favorite Markdown editors for writing

While these are my top picks, it doesn’t mean that if an app isn’t on this list that it’s bad. There are several good apps that I didn’t mention because they had too many features or were too expensive given the number of decent free or cheap options. And similar to IDE packages, there are a ton of Markdown apps out there and I haven’t tried them all (but I have tried a lot of them!).

A note about features that help you get “into the zone,” such as “typewriter” or “focus” modes, or soothing background music. They’ve never really worked for me and I eventually turn them off, so they aren’t a feature that I go looking for. (Although if you are into those, you can try Typora, which is free (during Beta) and runs on Mac, Windows, and Linux.)

My top choice

MacDown

Free; Mac

Meets all the criteria listed above. It’s light and snappy, and open source.

A good, similar alternative for Windows and Linux is Ghostwriter (also free).

Honorable mentions

Lightpaper

$ 15; Mac

Good for if you want just a bit more functionality. It adds a third pane so that you can easily switch between your files and folders.

Obsidian

Free for personal use; Mac, Windows, Linux

For a more full-featured app, the editor interface is pretty good, and meets most of the criteria mentioned above. Zettlr offers similar features, but just feels more complicated, IMO.

Byword

$ 11; Mac, iOS

Not my favorite app for writing and editing text, but it has the nice added ability to publish to various platforms (e.g., Medium, WordPress, Tumblr, Blogger, and Evernote).

Bear

Free or $ 1.49/mo. for Pro version; Mac, iOS

A good choice if you use Markdown for more than just site content (personal notes, task management, etc.). Scores high in appearance and usability, too.

Summary

With Markdown syntax being supported in more and more places — including Slack, GitHub, WordPress, etc. — it is quickly becoming a lingua franca for richer communication in our increasingly text-based lives. It’s here to stay because it’s not only easy to learn and use, it’s intuitive. And luckily we’re currently spoiled for choice when it comes to quality Markdown writing apps.


The post Considerations for Using Markdown Writing Apps on Static Sites appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , , ,
[Top]

Learn How to Build True Edge Apps With Cloudflare Workers and Fauna

(This is a sponsored post.)

There is a lot of buzz around apps running on the edge instead of on a centralized server in web development. Running your app on the edge allows your code to be closer to your users, which makes it faster. However, there is a spectrum of edge apps. Many apps only have some parts, usually static content, on the edge. But you can move even more to the edge, like computing and databases. This article describes how to do that.

Intro to the edge

First, let’s look at what the edge really is.

The “edge” refers to locations designed to be close to users instead of being at one centralized place. Edge servers are smaller servers put on the edge. Traditionally, servers have been centralized so that there was only one server available. This made websites slower and less reliable. They were slower because the server can often be far away from the user. Say if you have two users, one in Singapore and one in the U.S., and your server is in the U.S. For the customer in the U.S., the server would be close, but for the person in Singapore, the signal would have to travel across the entire Pacific. This adds latency, which makes your app slower and less responsive for the user. Placing your servers on the edge mitigates this latency problem.

Normal server architecture

With an edge server design, your servers have lighter-weight versions in multiple different areas, so a user in Singapore would be able to access a server in Singapore, and a user in the U.S. would also be able to access a close server. Multiple servers on the edge also make an app more reliable because if the server in Singapore went offline, the user in Singapore would still be able to access the U.S. server.

Edge architecture

Many apps have more than 100 different server locations on the edge. However, multiple server locations can add significant cost. To make it cheaper and easier for developers to harness the power of the edge, many services offer the ability to easily deploy to the edge without having to spend a lot of money or time managing multiple servers. There are many different types of these. The most basic and widely used is an edge Content Delivery Network (CDN), which allows static content to be served from the edge. However, CDNs cannot do anything more complicated than serving content. If you need databases or custom code on the edge, you will need a more advanced service.

Introducing edge functions and edge databases

Luckily, there are solutions to this. The first of which, for running code on the edge, is edge functions. These are small pieces of code, automatically provisioned when needed, that are designed to respond to HTTP requests. They are also commonly called serverless functions. However, not all serverless functions run on the edge. Some edge function providers are Lambda@Edge, Cloudflare Workers, and Deno Deploy. In this article, we will focus on Cloudflare Workers. We can also take databases to the edge to ensure that our serverless functions run fast even when querying a database. There are also solutions for databases, the easiest of which is Fauna. With traditional databases, it is very hard or almost impossible to scale to multiple different regions. You have to manage different servers and how database updates are replicated between them. Fauna, however, abstracts all of that away, allowing you to use a cross-region database with a click of a button. It also provides an easy-to-use GraphQL interface and its own query language if you need more. By using Cloudflare Workers and Fauna, we can build a true edge app where everything is run on the edge.

Using Cloudflare Workers and Fauna to build a URL shortener

Setting up Cloudflare Workers and the code

URL Shorteners need to be fast, which makes Cloudflare Workers and Fauna perfect for this. To get started, clone the repository at github.com/AsyncBanana/url-shortener and set your directory to the folder generated.

git clone https://github.com/AsyncBanana/url-shortener.git cd url-shortener

Then, install wrangler, the CLI needed for Cloudflare Workers. After that, install all npm dependencies.

npm install -g @cloudflare/wrangler npm install

Then, sign up for Cloudflare workers at https://dash.cloudflare.com/sign-up/workers and run wrangler login. Finally, to finish off the Cloudflare Workers set up, run wrangler whoami and take the account id from there and put it inside wrangler.toml, which is in the URL shortener.

Setting up Fauna

Good job, now we need to set up Fauna, which will provide the edge database for our URL shortener.

First, register for a Fauna account. Once you have finished that, create a new database by clicking “create database” on the dashboard. Enter URL-Shortener for the name, click classic for the region, and uncheck use demo data.

This is what it should look like

Once you create the database, click Collections on the dashboard sidebar and click “create new collection.” Name the collection URLs and click save.

Next, click the Security tab on the sidebar and click “New key.” Next, click Save on the modal and copy the resulting API key. You can also name the key, but it is not required. Finally, copy the key into the file named .env in the code under FAUNA_KEY.

Black code editor with code in it.
This is what the .env file should look like, except with API_KEY_HERE replaced with your key

Good job! Now we can start coding.

Create the URL shortener

There are two main folders in the code, public and src. The public folder is where all of the user-facing files are stored. src is the folder where the server code is. You can look through and edit the HTML, CSS, and client-side JavaScript if you want, but we will be focusing on the server-side code right now. If you look in src, you should see a file called urlManager.js. This is where our URL Shortening code will go.

This is the URL manager

First, we need to make the code to create shortened URLs. in the function createUrl, create a database query by running FaunaClient.query(). Now, we will use Fauna Query Language (FQL) to structure the query. Fauna Query Language is structured using functions, which are all available under q in this case. When you execute a query, you put all of the functions as arguments in FaunaClient.query(). Inside FaunaClient.query(), add:

q.Create(q.Collection("urls"),{   data: {     url: url   } })

What this does is creates a new document in the collection urls and puts in an object containing the URL to redirect to. Now, we need to get the id of the document so we can return it as a redirection point. First, to get the document id in the Fauna query, put q.Create in the second argument of q.Select, with the first argument being [“ref”,”id”]. This will get the id of the new document. Then, return the value returned by awaiting FaunaClient.query(). The function should now look like this:

return await FaunaClient.query(   q.Select(     ["ref", "id"],       q.Create(q.Collection("urls"), {         data: {           url: url,         },       })     )   ); }

Now, if you run wrangler dev and go to localhost:8787, you should see the URL shortener page. You can enter in a URL and click submit, and you should see another URL generated. However, if you go to that URL it will not do anything. Now we need to add the second part of this, the URL redirect.

Look back in urlManager.js. You should see a function called processUrl. In that function, put:

const res = await FaunaClient.query(q.Get(q.Ref(q.Collection("urls"), id)));

What this does is executes a Fauna query that gets the value of the document in the collection URLs with the specified id. You can use this to get the URL of the id in the URL. Next return res.data.url.url.

const res = await FaunaClient.query(q.Get(q.Ref(q.Collection("urls"), id))); return res.data.url.url

Now you should be all set! Just run wrangler publish, go to your workers.dev domain, and try it out!

Conclusion

Now have a URL shortener that runs entirely on the edge! If you want to add more features or learn more about Fauna or Cloudflare Workers, look below. I hope you have learned something from this, and thank you for reading.

Next steps

  • Further improve the speed of your URL shortener by adding caching
  • Add analytics
  • Read more about Fauna

Read more about Cloudflare Workers


The post Learn How to Build True Edge Apps With Cloudflare Workers and Fauna appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , , , ,
[Top]

Designing calculator apps

It is extremely weird that the calculator apps, even the default ones baked into desktop operating systems, embrace the UI and UX of those little cheap-o plastic physical calculators. I like what Florens Verschelde’s Math teacher had to say:

I had a Math teacher who would ban pocket calculators that didn’t show both your input and its result at the same time. If a calculator couldn’t show this:

38 ÷ 1.2 =    31.666666666667

You couldn’t use it.

The article ends up being in praise of Soulver, which I agree is a nice modern take on the idea of calculations.

I wish it was on Setapp, as I’d probably use it. But I don’t do enough regular mathin’ to go for the full price (today, anyway).

Direct Link to ArticlePermalink


The post Designing calculator apps appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

Progressive Web Apps in 2021

Maximiliano Firtman has a look at PWAs this year, including trying to get a bead on how widespread they are:

At the end of 2020, approximately 1% of websites included a Service Worker, and 2.2% had an installable Web App Manifest file. Remember that some platforms -such as Safari on iOS or Chrome on Android- do not require a Service Worker to have a standalone experience after installation. We can assume that 2.2% of websites are installable, and 1% may pass the PWA criteria on Android, 71% of which offer some offline experience.

That data is from the HTTP Archive, which looked at 7.5 million websites. So 1% might seem like a small number, but that’s lots of sites with PWA tech on them, and 170% year-over-year growth. Those are just the minimum requirements, though. I’m sure fully embracing PWA-ness (e.g. real offline usage) is a tiny fraction of that. Maximiliano has lots of more detailed data, so be sure to dig into the article if you’re interested in the nuance.

Anecdotally, I’d say PWAs fell out of general conversation last year. I don’t think anybody is exactly against the technologies that make them up, but they aren’t embracing them either. My guess? Everyone is scared of Service Workers. I’m scared of Service Workers. They do scary things, like aggressively hold onto cache. I think a whole dev team really needs to understand them and embrace them into their workflow and build process for them to be effective. Generally speaking, we just aren’t there yet.

Direct Link to ArticlePermalink


The post Progressive Web Apps in 2021 appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

Weekly Platform News: Web Apps in Galaxy Store, Tappable Stories, CSS Subgrid

In this week’s roundup: Firefox gains locksmith-like powers, Samsung’s Galaxy Store starts supporting Progressive Web Apps, CSS Subgrid is shipping in Firefox 70, and a new study confirms that users prefer to tap into content rather than scroll through it.

Let’s get into the news.

Securely generated passwords in Firefox

Firefox now suggests a securely generated password when the user focuses an <input> element that has the autocomplete="new-password" attribute value. This option is also available via the context menu on any password field.


(via The Firefox Frontier)

Web apps in Samsung’s app store

Samsung has started adding Progressive Web Apps (PWA) to its app store, Samsung Galaxy Store, which is available on Samsung devices. The new “Web apps” category is visible initially only in the United States. If you own a PWA, you can send its URL to pwasupport@samsung.com, and Samsung will help you get onboarded into Galaxy Store.

(via Ada Rose Cannon)

Tappable stories on the mobile web

According to a study commissioned by Google, the majority of people prefer tappable stories over scrolling articles when consuming content on the mobile web. Google is using this study to promote AMP Stories, which is a format for tappable stories on the mobile web.

Both studies had participants interact with real-world examples of tappable stories on the mobile web as well as scrolling article equivalents. Forrester found that 64% of respondents preferred the tappable mobile web story format over its scrolling article equivalent.

(via Alex Durán)

The grid form use-case for CSS Subgrid

CSS Subgrid is shipping in Firefox next month. This new feature enables grid items of nested grids to be put onto the outer grid, which is useful in situations where the wanted grid items are not direct children of the grid container.

(via Šime Vidas)

The post Weekly Platform News: Web Apps in Galaxy Store, Tappable Stories, CSS Subgrid appeared first on CSS-Tricks.

CSS-Tricks

, , , , , , , ,
[Top]

Why Progressive Web Apps Are The Future of Mobile Web

Here’s one of the best essays I’ve ever read about why progressive web apps are important, how they work, and what impact they have on a business:

PWAs are powerful, effective, fast and app-like.

It’s hard to imagine a mobile web property that could not be significantly improved via PWA implementation. They can also potentially eliminate the need for many “vanity” native apps that exist today.

My only small disagreement with this piece is their use of the term “mobile web.” I know it’s a tiny thing to get persnickety over but my hot take after reading it is this: it’s important to remember that progressive web apps are for everyone, desktop and mobile users alike. I think it’s important to reiterate that there is no mobile web. And that our goal is to be better than native.

Direct Link to ArticlePermalink

The post Why Progressive Web Apps Are The Future of Mobile Web appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Currently Reading: Progressive Web Apps by Jason Grisby

I’ve been reading Jason Grigsby’s new book on progressive web apps this past week and it’s exciting. Jason explains what PWAs are and how they work while while doing a bang-up job covering the business case for using them them, too. But perhaps you might be thinking that a PWA isn’t necessary for the project you’re working on right now. Well, Jason argues that progressive web apps are for everybody:

Should your website be a progressive web app? The answer is almost certainly yes. Even if you don’t think of your website as an “app,” the core features of progressive web apps can benefit any website. Who wouldn’t profit from a fast, secure, and reliable website?

One of the challenges I’ve experienced when thinking about how to apply a progressive web app to a project I’m working on is figuring out what content to cache. Should the homepage be cached? Do we make a custom offline page? What is useful information to provide a user in that context?

Jason goes there, too, and even describes how he tackles that for his own projects:

For cloudfour.com, we chose to only cache recently viewed pages because the main reason people come to our site is to read the articles. If we tried to anticipate which articles someone would want offline access to, we’d likely guess incorrectly. If we precached top-level pages, we might force people on a metered network connection to download content they would never look at…

That makes a ton of sense to me and I realize that the offline cache should probably be different depending on the situation and the website. For example, maybe a design agency website could replace the big flashy homepage with an offline page that only shows the phone number of the agency instead. Or perhaps a restaurant website could cache the food menu and make that experience offline, but remove all the images to make sure it’s not too impactful for folks on those metered networks.

Anyway, I think that Jason’s book is wonderful as it reveals to us all this complexity and a whole new set of opportunities to improve the design and experience of our websites, which, by the way, is something we should strive for in this new and exciting age of web app development.

The post Currently Reading: Progressive Web Apps by Jason Grisby appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

STAR Apps: A New Generation of Front-End Tooling for Development Workflows

Product teams from AirBnb and New York Times to Shopify and Artsy (among many others) are converging on a new set of best practices and technologies for building the web apps that their businesses depend on. This trend reflects core principles and solve underlying problems that we may share, so it is worth digging deeper.

Some of that includes:

Naming things is hard, and our industry has struggled to name this new generation of tooling for web apps. The inimitable Orta Theroux calls it an Omakase; I slimmed it down and opted for a simpler backronym pulled from letters in the tooling outlined above: STAR (Design Systems, TypeScript, Apollo, and React).

(more…)

, , , , , ,
[Top]