Articles

Case Study: Redesigning Todoist for Android

,

Todoist is a to-do list app that 25 million people rely on every day to keep their lives organized. As part of the Doist design team’s goals for 2021, we aimed to redesign the Todoist Android app to take advantage of the latest Google Material Design guidelines.

In this post, we cover the design decisions and processes behind redesigning the Todoist Android app for Material Design. We explore the Design and Android team’s collaboration practices that brought the app update to life, which resulted in winning the Material Design Award 2021 in the large screen category. Let’s get started!

Opportunity

When we started the project, our design implementation on Android was ready for a major overhaul. The last milestone redesign on Android was initiated after the release of the first Material Design guidelines in 2016. Since then the team successfully worked on continuous improvements to the Android app, but we saw the opportunity to improve Todoist on Android on a more holistic level.

We set out to clean up instances of older UI components, colors, and text styles and update them with the latest Material Design components. We observed that some interactions and navigational patterns had become inconsistent with what users were expecting on newer Android devices and were eager to modernize this experience. With new hardware and software changes in mind, we set out to make the experience on larger phones and tablets even better, so Todoist could take full advantage of the latest generation of devices. Material 2 and 3 provided an incredible new framework to rethink the current app experience. With this in mind, we set out to challenge what a modern Android app should look like and innovate on top of the default user experience.

Solution

The team set itself the goal of redesigning our Todoist Android app and aspiring to make it the best-designed productivity app on Android. The project was ambitious and scheduled to take several months to complete. We set ourselves the following targets while working on the project:

  • Review the current implementation and older design specs.
  • Study the latest Material Design Guidelines and assess what is relevant for our project.
  • Research great Material Design apps and case studies and learn from their execution.
  • Define the new Todoist Android app design language and document the changes.
  • Design and development work together to assess the proposed solution and implementation.
  • Test an early version of the new app internally to gather feedback and make adjustments.
  • Invite beta testers to the new app to gather feedback and make adjustments.
  • Refine the app and address core issues before launching to the public.

Review

The project was kicked off by reviewing the current Todoist Android app implementation, noting down what areas needed to be fixed and what was up to date. While reviewing, we took screenshots of the app implementation for reference. This way we could easily see the current state of the app and compare it to the new design proposals that would be created. Once the review process was finalized, we had a comprehensive overview of the current state of the app and the layout, component, and styling changes we wanted to make.

Study

We continued the project by studying the latest Material Design Guidelines, assessing the components and practices that were most relevant to Todoist.

When the project kicked off in February 2021, Material 2 was the most recent version of their design system. Since Material 2 had already been released for quite some time, we anticipated that design changes to Material would be announced soon at the Google I/O event in May 2021. Rather than wait, because we expected the changes to be iterative, we pushed ahead with our work.

We identified 25 components and UI patterns that we wanted to change across the app. The changes included buttons, forms, menus, sheets, navigation drawer, app bar, system bars, text and color styles, and more. We started by creating a table view in a Dropbox Paper document with the component changes and references links to Google’s Material Design Guidelines.

This components list was a starting point for discussion to plan the scope and complexity of the changes. Close async discussions between the design and development team in Twist and Dropbox Paper comments helped us make decisions about scope and complexity early on and set a solid foundation for the project.

Research

In the initial Material Design study, we also researched inspiring Material Design apps, Material studies, Play Store apps, and Google Workspace apps to learn from their execution.

We started out by studying the Material Design Award Winners 2020 and tested out the products that were showcased. The showcased winners struck a good balance between implementing the Material Design Guidelines while maintaining their own product’s brand within the system. This balance between Google’s guidelines and the Todoist brand was also key for us to get right and so we strived to find this mix across the work we created and implemented in the project.

Along with the MDA winners, we researched the Material Studies that Google produced to showcase what apps could look like with branding and Material Design guidelines applied. It was a great reference to see how far components could be customized while maintaining the core platform principles. The Reply case study in particular offered valuable insight to us as its content type and layout came closest to Todoist. It showcased how components like the app bar, navigation drawer, and large screen layouts worked while being customized.

We continued our research by searching the Google Play store for inspiring app examples. Google Tasks, Press, Periodic Table, and Kayak stood out to us as the level of polish and quality of the apps were on par with the experience we were aspiring to create.

Sometime later in the project when Material You was released (more on that later), we stumbled upon the Google Workspace apps blog post which previewed Material 3 changes that Google was introducing to their own products. It offered a great glimpse at what was to come before the Material 3 Design Guidelines were officially released. This post sparked new internal discussions and further design explorations that we considered for future Todoist Android updates.

Design Spec

As we started to define the new Todoist Android app design language and document the changes, we opted to create a design framework, focusing on creating components rather than designing every screen in the app. This allowed us to consistently apply the design system in the app. We did so by using the previously defined component list that we created during the review and study process.

Core screens from different areas of the app were chosen to demonstrate how the components could be applied. We chose to mock up the Todoist project view, navigation drawer menu, project view edit screen, settings, and project detail view, among others. These screens gave us a good overview of how buttons, forms, drawers, lists, and other components would work together and in different states; selected, pressed, disabled, etc.

During the project, we were transitioning our Doist design system to Figma and started creating our first components in the new Doist Product Android Library. We started by using some components from the Material Design UI kit – Components library from the official Google Figma resource file and added them to our Doist design system. We then continued to build up the Product Android Library file with our Todoist-specific components such as task list & board views, detail views, sheets, colors, typography, etc.

We continued by documenting color and typography changes that were based on the Material Design guidelines. The design team opted to implement a new Design Token framework that would share the same values between our design system and the development implementation. The development team would output the values they had in the current implementation and the design team would analyze which values were needed and which could be merged, changed, or deleted. This informed the new Design Token color and typography system which we then documented and discussed with the team to implement. Later in the project, we were happy to see a similar token system introduced by Material 3 in the latest guidelines which validated our thinking and principles behind the new design system.

The design documentation expanded to hold other edge-case mockups that could sit alongside the design system. We documented different responsive screen experiences between phones and tablets against the previous implementation. Additional sections were created to document the motion that should be used for certain components and screens by referencing existing Material Design guidelines examples or prototyping custom motion in Principle and After Effects. The design spec also touched on haptic feedback that should appear on touch targets, how dark mode should work across the new components, documenting Todoist themes within the new design language, and more.

Design Implementation

At Doist, the benefit of the squad is that cross-team collaboration is built into the make-up of the team. Designers, developers, support, and product managers work together in a squad to deliver the project. This close collaboration from the start is key to bridging the gap between scope, estimations, design, development, and delivery. The squad discussed their findings on a daily basis and came up with the best plan of action together.

Designers started by creating components in Figma and shared them with developers in Dropbox Paper. We used screenshots to document the current implementation next to the new designs and linked to the default Google Material Design components. This allowed the team to compare all references in one place. Developers shared their feedback, adjustments would be brainstormed together as the designs were iterated.

Designers on the project would share their work in progress on a weekly basis with the rest of the design team in a design review Twist thread. Here details about the designs were discussed, alternatives mocked up and bigger picture plans made. Design reviews brought up topics like FAB (Floating Action Button) placement, theme options, accent color usage on components, consistency with other platforms, navigation options, and shadow elevation. After thorough discussions and alternative mockups were presented, the design team aimed to find the right balance between Material Design and Todoist brand guidelines. The development team, also part of the design reviews, gave their feedback on the solution and raised technical complexities early on.

Eventually, the design was stabilized and consistencies updated across components and mockups. The design spec was kept up to date so the development team could always review the latest designs in Figma.

Testing

As soon as the development process started, the Android team provided early screenshots and videos in Twist threads while they were implementing the design spec. This practice allowed us to review the app implementation early and often. Designers could review the development work and share feedback in Twist, which resulted in getting the implementation to a high quality. Alongside Twist discussions, the team set up a Todoist project to track ongoing issues and fix bugs. Designers logged new issues, developers would solve them and share the new implementation for designers to review.

When the team had the first stable version of the Android app, we shared it internally at Doist to get more insight and feedback. Other Doisters could access the redesign via a feature flag that could be turned on in the app settings and test the new version for however long they wanted. The feature flag system allowed people to give us early feedback on the design decisions we made and report bugs. Feedback was submitted by the wider team through a dedicated Twist thread and designers and developers could discuss how best to address the feedback during the active project implementation.

After we refined the app implementation further and addressed early feedback we opened up the app update to our beta users. Here users had access to the new Android redesign and were able to give us feedback. Our support team gathered feedback and shared it with us in a dedicated Twist thread. The squad aimed to analyze every comment and looked for patterns where we could make tweaks and improvements to the user experience.

As part of these tweaks, we made changes to how the bottom bar and navigation drawer worked. Some users reported frustrations with the way the new bottom navigation and menu drawer worked. In its first implementation, the drawer was half raised when opened and had to be swiped up to be raised again to see the full content list. This was an issue for some users as it was slower to get to the content below the list. So we decided to fully raise the drawer by default when opening. We also made it easier to open the navigation drawer by sliding up from the bottom app bar. This was a small shortcut but it enabled users to get to their content faster.

Material You

While we were in the testing phase and about to wrap up the project, Google unveiled Material You, and sometime later the Material 3 Guidelines were published. With the newly announced resources, we went back to study the latest guidelines and references we could find to see where the Todoist Android app redesign fits in and which adjustments we might need to make now or in the future.

Dynamic Color was a big new feature that was announced as part of the Material You update. As Todoist supports many different themes the Material You Dynamic Color feature seemed like a good fit for our product. We decided to prioritize this feature and implement Dynamic Color light and dark themes as part of our Todoist theme settings options.

To implement Dynamic Color, the development team started off by creating a demo prototype that utilized the Dynamic Color system and showcased how we could select from a range of color choices that the system defined based on the wallpaper choice. From there, we tried to incorporate system behavior in our design mockups. We designed a range of different color mockups and components to see which ones could fit with which components. We then came up with a color system that worked for the Todoist app and the new themes. These new Dynamic Color themes would sit alongside our current theme options in the Todoist app settings. From here users could choose between Dynamic Color Light and Dark themes.

Along with Dynamic Color, the team also created a customizable bottom app bar, allowing users to set up the app in a way that’s most convenient to their workflow. The location of the Dynamic Add Button can be changed to the center, left, or right corner of the screen. The order of the Menu, Search, and Notification buttons can be rearranged to best fit the ergonomics of the user’s dominant (left or right) hand and optimize their navigation patterns.

Launch

As critical beta feedback was addressed and stability tweaks were made, the squad felt ready to release the new Todoist Android app to the public. The team logged the issues that could not immediately be addressed for future reviews and updates.

The design and marketing team readied the launch by creating What’s New banner artwork and copy that are displayed within the app when launching the update. The Doist marketing team also created release notes and shared the app update announcements on our social channels. The brand and product design team worked together to create custom image assets and copy that summarised the project work in a simple and beautiful way.

What’s Next: Material 3

After a successful launch of the redesigned Todoist for Android app, Google contacted Doist to announce that Todoist was selected as the Material Design Award 2021 winner in the Large Screen category. The team was excited to be recognized for their hard work and it felt like we achieved the goal we had set out to accomplish.

Internally, designers and developers continued to study and discuss the Material 3 updates. The design team started exploring mockups and design changes inspired by Material 3 and Google’s Workspace app updates. Some of our current Todoist explorations include changing the FAB styling, updating the app bar, further removing elevation shadows, and more. Here is a preview of what a future Todoist update could look like.

We hope these insights into Doist’s design process and collaboration practices have sparked your interest. Thank you for reading and stay tuned for future design updates!

Takeaways

  • Study the Material guidelines, Material Design winners, Material studies, and Google Workspace apps to make informed design decisions when designing your next product or app update.
  • Evaluate which Material Design components and practices are right for you and implement them into your product.
  • Carefully balance the Material Design guidelines with your brand guidelines to create a unique and consistent experience between your product and the platform it lives on.
  • Collaborate with your Android developers early and often to ship app updates efficiently and increase the design implementation quality.
  • Use design components and build a design system along with practical mockups to create an efficient design spec.
  • Consider how the latest Android features fit into your product and which have the most impact on your users before deciding to implement them.
  • Test and review builds with your internal team and external beta users to get valuable feedback and make adjustments before releasing them to the public.
  • Create announcement artwork to showcase your latest app or feature update along with a clear description to share in-app and on social media.

Source

The post Case Study: Redesigning Todoist for Android first appeared on Webdesigner Depot.

Source de l’article sur Webdesignerdepot

/par

Simplify Java Persistence Implementation With Kotlin on Quarkus

,

For decades, developers have struggled with optimizing persistence layer implementation in terms of storing business data, retrieving relevant data quickly, and — most importantly — simplifying data transaction logic regardless of programming languages.

Fortunately, this challenge triggered the invention of Java ecosystems in which developers can implement the Java Persistence API (JPA). For instance, Hibernate Object-Relational Mapper (ORM) with Panache is the standard framework for JPA implementation in the Java ecosystem.

Source de l’article sur DZONE

/par

Messaging Design Pattern (MDP) In Java

,

In this video tutorial below, we take a closer look at Messaging Design Pattern(MDP) in Java. This tutorial includes an introduction and implementation of a proxy, adapter, and web service. Let’s get started!

Source de l’article sur DZONE

/par

7 Worst Fails in Email Marketing

,

The email channel is known for multiple advantages. It is convenient to implement practically, offers many options, and has a fantastic ROI of up to 4200%.

But we also face problems, the most disappointing of which is people ignore emails, not performing the desired action, or worst of all unsubscribing. Why does it happen?

The web is constantly progressing. It offers many tools like modern HTML template builders, ESP services, and other digital assistants that help us at all stages. But even the best tools are not enough; the secret of success still rests with us.

In this post we’ll cover the 7 cardinal sins of email marketing, to help you avoid them.

1. Being Too Late

I can define this mistake as probably the worst. It’s worse than broken links, incorrect dates, or prices. Even more harmful than ugly design.

We lose a lot when postponing email strategy implementation. Beginners often focus all their attention on the content, social media activities, SEO issues… All that is important, right. But ignoring email campaigns is a hard fail.

Thousands of visitors never come again to your website. In other words, they leave the very first levels of the marketing funnel. While regular emailing keeps them engaged and prevents churn.

So delays here are only profitable for competitors. Don’t wait until you collect “enough” contacts. Start as soon as possible. 

Frequency matters too. Don’t bomb people with emails; it annoys and causes unsubscribes. Email frequency is an individual parameter depending on many factors.

2. Disregarding Clients’ Expectations

A fundamental axiom: people unsubscribe when emails are irrelevant. The same goes for neglected expectations. Even the best content with next-gen features won’t save the situation.

I mentioned the email frequency a bit above. Notice that if you announce the weekly emails but send them every day, this is an example of ignoring expectations. Be honest with readers.

Another typical issue is off-topic. If your subscribers are waiting for content related to smartphones, send them newsletters about smartphones, not dresses or domestic turtles :)

But in some cases, getting off-topic can be good. It all depends on the target audience, actual situation, and communication style. 

3. Bad Segmentation 

Once again, relevance is vital. So we must avoid generic emails. Instead, especially if your contact list is extensive enough, apply all the possible parameters: age, gender, location, customers history, etc.

Where to get the respective data? A typical solution is to use update preferences forms in emails or on the website. Let clients choose the topics that are interesting for them.

Use surveys, sign-in forms, AI-based techniques of segmentation… Smart algorithms are great helpers that track clients’ behavior and then process the data for segmentation purposes. 

The better we know our subscribers, the deeper we segment the contact list. It allows sending precisely targeted newsletters to respective segments.

4. Insufficient Personalization 

As Hubspot stats say, personalized emails’ open rate is 26% higher, and their click-through rate is 14% better. But even besides index data, poor personalization is just nonsense today.

Clients are looking for content that matches their preferences, so marketers have to consider these expectations. Segmentation and dynamic range are essential here, but they are not the only techniques.

Everything is much more sophisticated here, in addition to personalized subjects and content. Another solution is to generate recommendations that include the previously browsed products.

AI-powered automation comes to help. Machines will upgrade the classical personalization to the next level called hyper-personalization.

5. Underestimating Mobile-Friendliness 

It’s simply unacceptable to send non-responsive emails today. With so many people opening email on different devices, this is a huge fail.

The modern world is full of gadgets and devices. Email has been opened on smartphones more frequently than on desktop PCs and notebooks in recent years. Up to 70% of readers will read messages on mobiles very soon. No wonder that responsivity turned into a mobile priority.

Regarding layout and design, there are no problems: modern template editors are featured with automated responsivity. But mobile-first means not only layout/design adjustment for mobiles, full-width buttons, or larger fonts. We have to work with content too. Don’t overwrite text remember that recipients read inbox emails on the run. 

Just imagine yourself reading emails in the cafe or cab. And ask yourself: is everything convenient? Would you take the desired action on the run?

6. Non-Professional Approach 

People are quite skeptical of new brands. We need to do our best to attract them. So everything must be done professionally.

The best solution: be a perfectionist. If newsletters look amateurish, they are likely to repel.  

Being amateurish will also ruin your brand identity and reduce customers’ trust. Pay close attention to design, stick to your corporate style, analyze each detail in the context of overall harmony.

7. Overlooking Tests and Improvements 

Testing is vital. Before sending an email campaign, check it via Litmus or Email on Acid to be sure that message looks just as planned. These tools allow testing email rendering by +90 combinations of email clients, devices, and OS.

Knowledge is power. Always try and test your marketing strategies. Are you satisfied with your actual performance? Run A/B tests and focus on the most significant wins and failures. 

Summing Up

Of course, threats are not limited to these seven failures. The last piece of advice: never ignore trends. 

Accessibility? Don’t forget about clients with special requirements. Get whitelisted and incorporate these technologies in your campaigns.

And constantly strive for perfection. With this doctrine, you’ll win!

 

Featured image via Pexels.

Source

The post 7 Worst Fails in Email Marketing first appeared on Webdesigner Depot.

Source de l’article sur Webdesignerdepot

/par

Java: State Design Pattern

,

In the video below, we take a closer look at the State Design Pattern in Java. This tutorial includes an introduction, real-time examples, class/sequence diagram, and implementation. Let’s get started!

Source de l’article sur DZONE

/par

WordPress Website Analysis: Before & After ImageEngine

,


WordPress is by far the world’s most popular CMS. Not only does it dominate the CMS market with a 64% market share, but it also powers 39.6% of all websites. It has taken the internet by storm by democratizing the web for all. Now, anyone can build, manage, and host a successful website without needing a college degree or coding expertise.

However, while WordPress is great at managing many technical aspects, it still can’t do everything for you. Built mostly on PHP, there are often concerns regarding how performant WordPress is. And, with performance impacting everything from bounce rates to SEO rankings to conversions, it’s something that should be on your radar too.

If you don’t know it yet, images are one of the main causes of slow-loading websites. In recent years, WordPress has stepped up its efforts to try and help users with image optimization out-of-the-box.

Still, as we’ll show, it’s not a total solution, and there is still plenty you can do to deliver better experiences on your WordPress website through image optimization.

What is WordPress Image Optimization? Why is it Important?

Simply put, image optimization is anything you do to make images load faster on your website pages. Almost all websites that use images can benefit from some form of image optimization, even those using WordPress.

Why?

Well, performance is a hugely significant factor when it comes to the competitiveness of your website today.

Google has also made performance an increasingly important factor when it comes to SEO rankings. In fact, performance is a direct ranking signal that carries significant weight.

Google’s Page Experience Update that went live in 2021 has been the biggest move in that direction yet. Soon, Google might even use visual indicators in SERP results to distinguish high-performing websites from the rest.

In Google’s own words, “These signals measure how users perceive the experience of interacting with a web page and contribute to our ongoing work to ensure people get the most helpful and enjoyable experiences from the web.”

So, Why Should We Target Images For Performance Optimization?

According to Google, images are the largest contributor to page weight. Google has also singled out image optimization specifically as the factor with the most untapped potential for performance optimization.

This problem isn’t going away soon. According to data by the HTTP Archive, there are roughly 967.5 KB bytes of image data on desktop web pages and 866.3 KB of image data on mobile pages. This is an increase of 16.1% and 38.8%, respectively, over the last five years.

Thanks to popular e-commerce tools like Woocommerce, it’s estimated that up to 28% of all online sales happen on WordPress websites.

And don’t forget, images are both a key part of conveying information to the user and integral to the design of your website. If they take significantly longer to load than your text, for example, it will negatively impact the user experience in a variety of ways.

In summary, optimized images help your WordPress website by:

  • Improving user satisfaction.
  • Improving various traffic metrics, like bounce rates, time-on-page, etc.
  • Boosting your SEO rankings.
  • Contributing to higher conversions (and sales).

How Does Image Optimization in WordPress Work?

WordPress is so popular because it’s a CMS (content management system) that allows anyone to build, design, and manage a website without any coding or advanced technical experience. Advanced features can be installed with just a few clicks, thanks to plugins, and you rarely have to touch the code behind your website unless you want to make some unique modifications.

In short, using a CMS like WordPress shields you from many of the day-to-day technicalities of running a website.

WordPress Image Optimization: What It Can Do

As we mentioned, one of the main reasons WordPress is so popular is because it takes care of many of the technical aspects of running a website. With that in mind, many think that WordPress should also automatically take care of image optimization without them having to get involved at all.

Unfortunately, that’s not really the case.

True, WordPress does offer some built-in image optimization. Whenever you upload an image to WordPress, it currently compresses the quality to about 82% of the original (since v4.5).

In v4.4, WordPress also introduced responsive image syntax using the srcset attribute. This creates four breakpoints for each image you upload according to the default WordPress image sizes:

  • 150px square for thumbnails
  • 300px width for medium images
  • 768px max-width for medium_large images
  • 1024px max-width for large images.

Here you can see an example of the actual responsive syntax code generated by WordPress:

<img loading="lazy" src="https://bleedingcosmos.com/wp-content/uploads/2021/12/33-1024x683.jpg" alt="" class="wp-image-9" width="610" height="406" srcset="https://bleedingcosmos.com/wp-content/uploads/2021/12/33-1024x683.jpg 1024w, https://bleedingcosmos.com/wp-content/uploads/2021/12/33-300x200.jpg 300w, https://bleedingcosmos.com/wp-content/uploads/2021/12/33-768x512.jpg 768w, https://bleedingcosmos.com/wp-content/uploads/2021/12/33-1536x1024.jpg 1536w" sizes="(max-width: 610px) 100vw, 610px">

Depending on the screen size of the device from which a user visits your webpage, WordPress will let the browser pick the most appropriately sized image. For example, the smallest version for mobile displays or the largest for 4K Retina screens, like those of a Mac.

While this may seem impressive, it’s only a fraction of what can be achieved using a proper image optimization solution, as we’ll show later.

Lastly, WordPress implemented HTML native default lazy loading for all images starting with version 5.5.

So, in short, WordPress offers the following image optimization capabilities baked-in:

  • Quality compression (limited)
  • Responsive syntax (up to 4 breakpoints)
  • Lazy loading

WordPress Image Optimization: What it Cannot Do

There are other issues many have with both the implementation of image compression and responsive syntax as it’s used by WordPress. This leads to some users even purposefully deactivating WordPress’ built-in image optimization so they can fully take control of it themselves.

Here are some of the reasons why:

  • WordPress uses a very basic form of quality compression. It does not use advanced technologies like AI and machine learning algorithms to compress images while maintaining maximum visual quality. It’s also lossy compression, so the quality is lost for good. You can clearly see the difference between an original HD image and the compressed version created by WordPress.
  • WordPress only compresses most images by up to 20%, while advanced image optimization tools can reduce all image sizes intelligently by up to 80%.
  • Responsive syntax can provide significant performance improvements over simply uploading a single HD image to be served on all devices and screens. However, it’s still only limited to a set number of breakpoints (typically 3 or 4). Since it’s not dynamic, a whole spectrum of possible image sizes is not created or used.
  • Responsive syntax code is not scalable and can quickly lead to code that’s bloated, messy, and hard to read.
  • WordPress doesn’t accelerate image delivery by automatically caching and serving them via a global CDN, although this can be done using other tools.

Another important optimization feature that WordPress does not have is auto-conversion to next-gen image file formats. Different image formats offer different performance benefits on different devices. Some formats also enable higher levels of compression while maintaining visual fidelity.

Next-gen formats like WebP, AVIF, and JPEG-2000 are considered to be the most optimal formats on compatible devices. For example, until recently, WebP would be the optimal choice on Chrome browsers, while JPEG-4000 would be optimal on Safari browsers.

However, WordPress will simply serve images in the same formats in which they were originally uploaded to all visitors.

How to Measure the Image Performance of a WordPress Website?

As the undisputed king of search engines, we’ll base most of our performance metrics on guidelines established by Google.

Along with its various performance updates, Google has released a number of guidelines for developers as well as the tools to test and improve their websites according to said guidelines.

Google introduced Core Web Vitals as the primary metrics for measuring a web page’s performance and its effect on the user experience. Thus, Core Web Vitals are referred to as “user-centric performance metrics.” They are an attempt to give developers a testable and quantifiable way to measure an elusive and abstract concept such as “user experience.”

Combined with a number of other factors, Core Web Vitals constitute a major part of the overall page experience signal:

You can find a complete introduction to Core Web Vitals here. However, they currently consist of three main metrics:

  • LCP (Largest Contentful Paint): The time it takes the largest above-the-fold element on your page to load. This is typically a full-sized image or hero section.
  • FID (First Input Delay): The delay from the moment a user first interacts with an element on the page until it becomes responsive.
  • CLS (Cumulative Layout Shift): The visual stability with which the elements on a page load.

Here is an illustration of how these metrics are scored:

While these are the three most important metrics to optimize, they are not the only ones. Google still measures other metrics like the FCP (First Contentful Paint), SI (Speed Index), as well as the TTFB (Time to First Byte), TBT (Total Blocking Time), and TTI (Time to Interactive).

A number of these metrics are directly affected by the images used on your web pages. For example, LCP, FCP, and SI are direct indicators of how fast the content of your web page loads and depends on the overall byte size of the page. However, it can also indirectly affect FID by keeping the main thread busy with rendering large amounts of image content or the perceived CLS by delaying the time it takes large images to load.

These metrics apply to all websites, whether they are custom-made or built using a CMS like WordPress.

When using tools like Lighthouse or PageSpeed Insights, you’ll also get scored based on other flags Google deems important. Some of them are specific to images, such as properly sizing images and serving images in next-gen formats.

If you only use built-in WordPress image optimization, you’ll get flagged for the following opportunities for improvement:

Some of the audits it will pass, however, are deferring offscreen images (lazy loading) and efficiently coding images (due to compression):

A Better Way to Optimize WordPress Images: ImageEngine

Billions of websites are all vying for prime real estate on Google SERPs, as well as the attention of an increasingly fussy internet-using public. Every inch matters when it comes to giving your website a competitive advantage.

So, how can you eliminate those remaining performance flags and deliver highly optimized images that will keep both your visitors and Google happy?

Sure, you could manually optimize images using software like PhotoShop or GIMP. However, that will take you hours for each new batch of images. Plus, you still won’t benefit from any automated adaptive optimization.

A more reasonable solution in today’s fast-paced climate is to use a tool developed specifically for maximum image optimization: an image CDN like ImageEngine.

ImageEngine is an automated, cloud-based image optimization service using device detection as well as intelligent image compression using the power of AI and machine learning. It can reduce image payloads by up to 80% while maintaining visual quality and accelerating delivery around the world thanks to its CDN with geographically dispersed PoPs.

Why is ImageEngine Image Optimization Better Than WordPress?

When making a head-to-head comparison, here are the reasons why ImageEngine can deliver better performance:

  • Device Detection: ImageEngine features built-in device detection. This means it picks up what device a visitor to your website is using and tailors its optimization strategy to what’s best for that specific device.
  • Client hints: By supporting client hints, ImageEngine has access to even more information regarding the device and browser to make better optimization decisions.
  • Next-gen formats: Based on optimal settings, ImageEngine automatically converts and serves images in next-gen formats like WebP, AVIF, JPEG2000, and MP4 (for GIFs).
  • Save data header: When a Chrome user has save-data mode enabled, ImageEngine will automatically compress images more aggressively to save on data transfer.
  • CDN with dedicated edge servers: ImageEngine will automatically cache and serve your optimized image assets using its global CDN. Each edge server has device awareness built-in to bring down latency and accelerate delivery. You can also choose to prioritize specific regions.

So, the key differentiator is that ImageEngine can tailor optimizing images for what’s optimal for each of your visitors. ImageEngine is particularly good at serving mobile visitors thanks to WURFL device detection, which can dynamically resize images according to most devices and screen sizes in use today. As of now, this is a completely unique capability that none of its competitors offer.

It allows for far better and more fine-tuned optimization than WordPress’ across-the-board approach to compression and responsive syntax.

If you want, you could turn off WordPress responsive syntax and compression, and you would still experience a performance increase using ImageEngine. However, ImageEngine also plays nice with responsive syntax, so it’s not completely necessary unless you want to serve the highest-fidelity/low-byte-size images possible.

How Does ImageEngine Work with WordPress?

The process ImageEngine uses to integrate with WordPress can be broken down into a few easy steps:

  • Sign up for an ImageEngine account: ImageEngine offers three pricing plans depending on the scale and features you need as well as a no-commitment 30-day free trial.
  • Specify your image origin: This tells ImageEngine where to find the original versions of your images. For a WordPress website, you can just use your domain, e.g., https://mywordpresswebsite.com. ImageEngine will then automatically pull the images you’ve uploaded to your WordPress website.

  • Copy the Delivery Address: After you create an account and specify your image origin, ImageEngine will provide you with a Delivery Address. A Delivery Address is your own unique address that will be used in your <img> tags to point back to the ImageEngine service. Delivery Addresses may be on a shared domain (imgeng.in) or customized using a domain that you own. A Delivery Address typically looks something like {random_string}.cdn.imgeng.in. If your images are uploaded to the default WordPress folder /wp-content/uploads/, you can access your optimized images from ImageEngine simply by changing your website domain. For example, by typing {imageengine_domain}.cdn.imgeng.in/wp-content/uploads/myimage.jpg into your browser, you’ll see the optimized version of that image. Just press the copy button next to the Delivery Address and use it in the next step configuring the plugin.

  • Install the ImageEngine Optimizer CDN plugin: The plugin is completely free and can be installed just like any other plugin from the WordPress repository.
  • Configure and enable ImageEngine Plugin in WordPress: Just go to the plugin under “ImageEngine” in the main navigation menu. Then, copy and paste in your ImageEngine “Delivery Address,” tick the “Enabled” checkbox, and click “Save Changes” to enable ImageEngine:

Now, all ImageEngine basically does is replace your WordPress website domain in image URLs with your new ImageEngine Delivery Address. This makes it a simple, lightweight, and non-interfering plugin that works great with most other plugins and themes. It also doesn’t add unnecessary complexity or weight to your WordPress website pages.

ImageEngine vs Built-in WordPress Image Optimization

So, now let’s get down to business by testing the performance improvement you can expect from using ImageEngine to optimize your image assets.

To do this test, we set up a basic WordPress page containing a number of high-quality images. I then used PageSpeed Insights and the Lighthouse Performance Calculator to get the performance scores before and after using ImageEngine.

Importantly, we conducted this test from a mobile-first perspective. Not only has mobile internet traffic surpassed desktop traffic globally, but Google themselves have committed to mobile-first indexing as a result.

Here is a PageSpeed score using the Lighthouse calculator for WordPress with no image optimization:

As we can see, both Core Web Vitals and other important metrics were flagged as “needs improvement.” Specifically, the LCP, FCP, and TBT. In this case, both the LCP and FCP were a high-res featured image at the top of the page.

If we go to the opportunities for improvement highlighted by PageSpeed, we see where the issues come from. We could still save as much as 4.2s of loading time by properly resizing images and a further 2.7s by serving them in next-gen formats:

So, now let’s see how much ImageEngine can improve on that.

The same test run on my WordPress website using ImageEngine got the following results:

As you can see, we now have a 100 PageSpeed score. I saved roughly 2.5s on the SI (~86%) as well as roughly 1.7s on the LCP (~60%). There was also a slight improvement in the FCP.

Not only will you enjoy a stronger page experience signal from Google, but this represents a tangible difference to visitors regarding the speed with which your website loads. That difference will lead to lower bounce rates, increased user satisfaction, and more conversions.

There was also a 53% overall reduction in the total image payload. This is impressive, considering that it’s on top of WordPress’ built-in compression and responsive syntax.

Conclusion

So, as someone with a WordPress website, what can you take away from this?

Well, first of all, WordPress does feature some basic image optimization. And while not perfect, it should help you offer reasonable levels of performance, even if you use a lot of image content.

However, the caveat is that WordPress applies aggressive, across-the-board compression, which will lead to a noticeable reduction in visual quality. If you use WordPress for any type of website where premium quality images are important, this is a concern — for example, as a photography portfolio, exhibition, or image marketplace like Shutterstock.

By using ImageEngine, you can reduce image payloads and accelerate delivery even further without compromising too harshly on visual quality. What’s more, ImageEngine’s adaptive image optimization technology will provide greater improvements to more of your visitors, regardless of what device(s) they use to browse the web.

Whether or not you still want to use WordPress’ built-in optimizations, ImageEngine will deliver significant improvements to your user experience, traffic metrics, and even conversions.

Plus, true to the spirit of WordPress, it’s extremely simple to set up without any advanced configuration. Just sign up for ImageEngine in 3 easy steps, install the plugin, integrate ImageEngine by copy/pasting your image domain, and you’re good to go.

 

[ This is a sponsored post on behalf of ImageEngine ]

Source

The post WordPress Website Analysis: Before & After ImageEngine first appeared on Webdesigner Depot.

Source de l’article sur Webdesignerdepot

/par

Introduction to Couchbase for Oracle Developers and Experts: Part 5: Statements and Features

,

SQL is the only 22nd century tool available in 21st century

Here are the previous articles comparing architecture, database objects, data types, and data modeling of Oracle with Couchbase. This will focus on SQL support.  

Oracle was the first and staunch supporter of SQL. Oracle’s SQL implementation beat IBM to market by two years.  That changed the fortune of one or two people. :-) All of the modern relational databases implement SQL. So much so, the relational databases are sometimes called SQL databases, much to the chagrin of C. J. Date.  Nations are known by their languages… English, French, and American(!). It’s not a stretch for a class of database systems to be known by their languages as well.  SQL has been so effective, many big data and non-relational systems have picked up SQL as the lingua franca. SQL is here to stay, even for NoSQL systems. 

Source de l’article sur DZONE

/par

Adapter Design Pattern in Java: Mobile Charger

,

In the video below, we take a closer look at the adapter design pattern in Java (Mobile Charger). This tutorial includes an introduction, example, implementation, and more. Let’s get started!

Source de l’article sur DZONE

/par

A Beginner’s Guide to High-Performance Computing in Python

,
Ever since the Python programming language was born, its core philosophy has always been to maximize the readability and simplicity of code. In fact, the reach for readability and simplicity is so deep within Python’s root that, if you type import this in a Python console, it will recite a little poem:

    Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. The complex is better than complicated. The flat is better than nested. Sparse is better than dense. Readability counts…

Simple is better than complex. Readability counts. No doubt, Python has indeed been quite successful at achieving these goals: it is by far the most friendly language to learn, and an average Python program is often 5 to 10 times shorter than equivalent C++ code. Unfortunately, there is a catch: Python’s simplicity comes at the cost of reduced performance. In fact, it is almost never surprising for a Python program to be 10 to 100 times slower than its C++ counterpart. It thus appears that there is a perpetual trade-off between speed and simplicity, and no programming language shall ever possess both.
But, don’t you worry, all hope is not lost.

Taichi: Best of Both Worlds

The Taichi Programming Language is an attempt to extend the Python programming language with constructs that enable general-purpose, high-performance computing. It is seamlessly embedded in Python, yet can summon every ounce of computing power in a machine — the multi-core CPU, and more importantly, the GPU.
We’ll show an example program written using taichi. The program uses the GPU to run a real-time physical simulation of a piece of cloth falling onto a sphere and simultaneously renders the result.
Writing a real-time GPU physics simulator is rarely an easy task, but the Taichi source code behind this program is surprisingly simple. The remainder of this article will walk you through the entire implementation, so you can get a taste of the functionalities that taichi provides, and just how powerful and friendly they are.
Before we begin, take a guess of how many lines of code this program consists of. You will find the answer at the end of the article.

Algorithmic Overview

Our program will model the piece of cloth as a mass-spring system. More specifically, we will represent the piece of cloth as an N by N grid of point-masses, where adjacent points are linked by springs. The following image, provided by Matthew Fisher, illustrates this structure:
The motion of this mass-spring system is affected by 4 factors:
  • Gravity
  • Internal forces of the springs
  • Damping
  • Collision with the red ball in the middle
For the simplicity of this blog, we ignore the self-collisions of the cloth. Our program begins at the time t = 0. Then, at each step of the simulation, it advances time by a small constant dt. The program estimates what happens to the system in this small period of time by evaluating the effect of each of the 4 factors above, and updates the position and velocity of each mass point at the end of the timestep. The updated positions of mass points are then used to update the image rendered on the screen.

Getting Started

Although Taichi is a programming language in its own right, it exists in the form of a Python package and can be installed by simply running pip install taichi.
To start using Taichi in a python program, import it under the alias ti:
import taichi as ti
The performance of a Taichi program is maximized if your machine has a CUDA-enabled Nvidia GPU. If this is the case, add the following line of code after the import: ti.init(arch=ti.cuda)

If you don’t have a CUDA GPU, Taichi can still interact with your GPU via other graphics APIs, such as ti.metal, ti.vulkan, and ti.opengl. However, Taichi’s support for these APIs is not as complete as its CUDA support, so, for now, use the CPU backend: ti.init(arch=ti.cpu)And don’t worry, Taichi is blazing fast even if it only runs on the CPU. Having initialized Taichi, we can start declaring the data structures used to describe the mass-spring cloth. We add the following lines of code:

Python

  

 N = 128 x = ti.Vector.field(3, float, (N, N)) v = ti.Vector.field(3, float, (N, N))

Source de l’article sur DZONE

/par

Top 3 Chatbot Security Vulnerabilities in 2022

,

Article Image

Chatbots Are Here To Stay

Chatbots have been around for a long time and based on the global chatbot market size (and the expected growth), they will stick around for a long time and gain importance. In the past, they’ve rarely met customer expectations or provided much positive experience. However, over the last few years, advances in conversational AI have transformed how they can be used. Since chatbots offer a wide range of applications, in certain cases, they become responsible for collecting and protecting personal information as well. 
Consequently, they are a great attraction for hackers and malicious attacks too. The responsibility of ensuring chatbot security has become more evident after the introduction of GDPR in Europe. As statistics show that this technology will be a determining factor in our lives, security testing must also become part of our daily tasks, so that these chatbots can be used with confidence.

Security Risks, Threats, and Vulnerabilities                 

The words risk, threat, and vulnerability are often confused or used interchangeably when reading about computer security, so let’s first clarify the terminology:

  • Vulnerability refers to a weakness in your software (or hardware, or in your processes, or anything related). In other words, it’s a way hackers could find their way into and exploit your systems.
  • A threat exploits a vulnerability and can cause loss, damage, or destruction of an asset – threats exploit vulnerabilities.                
  • Risk refers to the potential for lost, damaged, or destroyed assets – threats + vulnerability = risk! 
The well-known OWASP Top 10 is a list of top security risks for a web application. Most chatbots out there are available over a public web frontend, and as such, all the OWASP security risks apply to those chatbots as well. Out of these risks, there are two especially important to defend against, as in contrast to the other risks, those two are nearly always a serious threat — XSS (Cross-Site Scripting) and SQL Injection.
In addition, for artificial intelligence-enabled chatbots, there is an increased risk for Denial of Service attacks, due to the higher amount of computing resources involved.

Vulnerability 1: XSS – Cross-Site Scripting

A typical implementation of a chatbot user interface:           

           

  • There is a chat window with an input box.
  • Everything the user enters in the input box is mirrored in the chat window.
  • Chatbot response is shown in the chat window.

The XSS vulnerability is in the second step — when entering text including malicious Javascript code, the XSS attack is fulfilled when the web browser is running the injected code:

 <script>alert(document.cookie)</script>              

Possible Attack Vector

For exploiting an XSS vulnerability the attacker has to trick the victim to send malicious input text. It can be done through one of the following ways:

/par