Archive

Archive for May, 2023

Create Your Own Path In June (2023 Wallpapers Edition)

May 31st, 2023 No comments

There’s an artist in everyone. Some bring their ideas to life with digital tools, others capture the perfect moment with a camera or love to grab pen and paper to create little doodles or pieces of lettering. And even if you think you’re far from being an artist, well, it might just be hidden deep inside of you. So why not explore it?

For more than twelve years already, our monthly wallpapers series has been the perfect opportunity to do just that: to break out of your daily routine and get fully immersed in a creative little project. This month was no exception, of course.

In this collection, you’ll find beautiful, unique, and inspiring wallpapers designed by creative folks who took on the challenge this month. All of them are available in versions with and without a calendar for June 2023 and can be downloaded for free. As a little bonus goodie, we also compiled a selection of timeless June wallpapers from our archives at the end of this post. Maybe you’ll spot one of your almost-forgotten favorites in there, too? A big thank-you to everyone who shared their designs with us this month! Happy June!

  • You can click on every image to see a larger preview,
  • We respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience through their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us but rather designed from scratch by the artists themselves.
  • Submit a wallpaper!
    Did you know that you could get featured in our next wallpapers post, too? We are always looking for creative talent.

World Environment Day

“An annual event celebrated on June 5th to raise awareness and promote action for the protection of the environment. It serves as a global platform for individuals, communities, and governments to come together and address pressing environmental issues. So I decided to design this wallpaper and to promote awareness among us. Hope you like it.” — Designed by Hrishikesh Shome from India.

Back In My Days

Designed by Ricardo Gimenes from Sweden.

Boundless Joy

“Boundless Joy is a magical realm where children and dogs find pure delight. It’s a place where laughter echoes through sunlit meadows and imaginations take flight. In this enchanting world, youthful spirits soar as kids and their furry companions chase dreams, playfully bound together. With every step, Boundless Joy sparks smiles, ignites friendships, and creates memories that last a lifetime.” — Designed by Kasturi Palmal from India.

Cuban Bartender

“Summer arrives and with it the long days and nights that allow us to enjoy the weather. We are heading to Cuba and from the Malecón we observe the city waiting for the new day.” — Designed by Veronica Valenzuela from Spain.

Blue Butterfly

“Captured with Sony A7II and FE 90mm F2.8 Macro lens. Macro photography is my favorite.” — Designed by Viktor Hanacek from Czechia.

Holding Out For Me

“Effectively captures the essence of a girl observing the view outside through a window. It conveys the image of someone attentively observing or gazing at what’s happening outside, suggesting a sense of curiosity or contemplation.” — Designed by Bhabna Basak from India.

Pre-Wash Instructions

Designed by Ricardo Gimenes from Sweden.

Summer Palms

“Looks like Bahamas, but these are from San Francisco! Yep, photographers’ secrets!” — Designed by Viktor Hanacek from Czechia.

Raise A Glass To World Milk Day

“World Milk Day is a reminder to appreciate the nourishing qualities of milk and the impact it has on our well-being. Whether enjoyed on its own, added to a smoothie, or used to create mouthwatering recipes, milk is a versatile and wholesome ingredient that deserves to be celebrated.” — Designed by PopArt Studio from Serbia.

Oldies But Goodies

So many wonderful wallpaper designs have seen the light of day since we first embarked on this monthly journey. Below you’ll find a selection of favorites from past June editions. Please note that these wallpapers don’t come with a calendar.

Create Your Own Path

“Nice weather has arrived! Clean the dust off your bike and explore your hometown from a different angle! Invite a friend or loved one and share the joy of cycling. Whether you decide to go for a city ride or a ride in nature, the time spent on a bicycle will make you feel free and happy. So don’t wait, take your bike and call your loved one because happiness is greater only when it is shared. Happy World Bike Day!” — Designed by PopArt Studio from Serbia.

Summer Coziness

“I’ve waited for this summer more than I waited for any other summer since I was a kid. I dream of watermelon, strawberries, and lots of colors.” — Designed by Kate Jameson from the United States.

Old Kyiv

“This picture is dedicated to Kiev (Kyiv), the capital of Ukraine. It is loosely based on a 13th century map — this is what the center of Kyiv looked like ca. 900 years ago! The original map also included the city wall — however, I decided not to wrap the buildings into the wall, since in my dream world, a city would not need walls.” — Designed by Vlad Gerasimov from Georgia.

Travel Time

“June is our favorite time of the year because the keenly anticipated sunny weather inspires us to travel. Stuck at the airport, waiting for our flight but still excited about wayfaring, we often start dreaming about the new places we are going to visit. Where will you travel to this summer? Wherever you go, we wish you a pleasant journey!” — Designed by PopArt Studio from Serbia.

Strawberry Fields

Designed by Nathalie Ouederni from France.

Oh, The Places You Will Go!

“In celebration of high school and college graduates ready to make their way in the world!” — Designed by Bri Loesch from the United States.

Expand Your Horizons

“It’s summer! Go out, explore, expand your horizons!” — Designed by Dorvan Davoudi from Canada.

Summer Surf

“Summer vibes…” — Designed by Antun Hirsman from Croatia.

Summertime

Designed by Ricardo Gimenes from Sweden.

Deep Dive

“Summer rains, sunny days, and a whole month to enjoy. Dive deep inside your passions and let them guide you.” — Designed by Ana Masnikosa from Belgrade, Serbia.

Join The Wave

“The month of warmth and nice weather is finally here. We found inspiration in the World Oceans Day which occurs on June 8th and celebrates the wave of change worldwide. Join the wave and dive in!” — Designed by PopArt Studio from Serbia.

Melting Away

Designed by Ricardo Gimenes from Sweden.

Bauhaus

“I created a screenprint of one of the most famous buildings from the Bauhaus architect Mies van der Rohe for you. So, enjoy the Barcelona Pavillon for your June wallpaper.” — Designed by Anne Korfmacher from Germany.

World Environment Day

“On June 5th, we celebrate World Environment Day — a moment to pause and reflect on how we impact Earth’s health. A few activities represented in this visual include conserving energy and water, shopping and growing local, planting flowers and trees, and building a sustainable infrastructure.” — Designed by Mad Fish Digital from Portland, OR.

Pineapple Summer Pop

“I love creating fun and feminine illustrations and designs. I was inspired by juicy tropical pineapples to celebrate the start of summer.” — Designed by Brooke Glaser from Honolulu, Hawaii.

Window Of Opportunity

“‘Look deep into nature and then you will understand everything better,’ A.E.” — Designed by Antun Hiršman from Croatia.

Midsummer Night’s Dream

“The summer solstice in the northern hemisphere is nigh. Every June 21 we celebrate the longest day of the year and, very often, end up dancing like pagans. Being landlocked, we here in Serbia can only dream about tidal waves and having fun at the beach. What will your Midsummer Night’s Dream be?” — Designed by PopArt Studio from Serbia.

Papa Merman

“Dream away for a little while to a land where June never ends. Imagine the ocean, feel the joy of a happy and carefree life with a scent of shrimps and a sound of waves all year round. Welcome to the world of Papa Merman!” — Designed by GraphicMama from Bulgaria.

Gravity

Designed by Elise Vanoorbeek (Doud Design) from Belgium.

Solstice Sunset

“June 21 marks the longest day of the year for the Northern Hemisphere — and sunsets like these will be getting earlier and earlier after that!” — Designed by James Mitchell from the United Kingdom.

Yoga Is A Light, Which Once Lit, Will Never Dim

“You cannot always control what goes on outside… you can always control what goes on inside… Breathe free, live and let your body feel the vibrations and positiveness that you possess inside you. Yoga can rejuvenate and refresh you and ensure that you are on the journey from self to the self. Happy International Yoga Day!” — Designed by Acodez IT Solutions from India.

Summer Things

“Summer is coming so I made this simple pattern with all my favorite summer things.” — Designed by Maria Keller from Mexico.

Night Night!

“The time we spend with our dads is precious so I picked an activity my dad enjoys a lot, reading.” — Designed by Maria Keller from Mexico.

Evolution

“We’ve all grown to know the month of June through different life stages. From toddlers to adults with children, we’ve enjoyed the weather with rides on our bikes. As we evolve, so do our wheels!” — Designed by Jason Keist from the United States.

Handmade Pony Gone Wild

“This piece was inspired by the My Little Pony cartoon series. Because those ponies irritated me so much as a kid, I always wanted to create a bad ass pony.” — Designed by Zaheed Manuel from South Africa.

Getting Better Everyday

“Inspired by the eternal forward motion to get better and excel.” — Designed by Zachary Johnson-Medland from the United States.

Comfort Reading

Designed by Bobby Voicu from Portugal.

Happy Squatch

“I just wanted to capture the atmosphere of late spring/early summer in a fun, quirky way that may be reflective of an adventurous person during this time of year.” — Designed by Nick Arcarese from the United States.

Categories: Others Tags:

3 Essential Design Trends, June 2023

May 29th, 2023 No comments
3 Essential Design Trends, June 2023

This month we are focusing on three trends within a bigger website design trend – different navigation menu styles and features. So many projects are featuring interesting navigation patterns right now as there’s a focus – and almost push and pull – on navigation that feels more consistent between devices.

Categories: Designing, Others Tags:

The Impact Of Agile Methodologies On Code Quality

May 25th, 2023 No comments

As software development continues to evolve, so too do the methodologies and approaches used to create it. In recent years, Agile methodologies have gained widespread adoption as a modern approach to software development, with a focus on flexibility, collaboration, and delivering working software in short increments. This is a key differentiator when it comes to other development workflows.

One of the key benefits of Agile methodologies is its impact on the quality of the code that ships. Code quality is an essential aspect of software development, as high-quality code is critical to ensure the reliability, maintainability, and scalability of any software, website, or application.

Overview Of Agile Methodologies

Agile methodologies are a set of software development approaches that prioritize flexibility, collaboration, and delivering working software in short increments. Agile methodologies aim to improve the quality of the software by allowing for frequent feedback, continuous improvement, and adaptation to changing requirements.

The Agile Manifesto, created in 2001 by a group of software developers who wanted to find a better way of developing software, outlines the core values and principles of Agile methodologies. These values include prioritizing individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change rather than following a concrete, long-term plan.

Agile methods break down projects into small and manageable units called sprints. Sprints are completed by cross-functional and self-organizing teams in a short period of time, usually two to four weeks. During each sprint, the team works on a specific set of tasks, and at the end of the sprint, they review their work, evaluate customer satisfaction, and identify areas for improvement. Because each sprint is focused on a specific set of tasks, the team can quickly pivot and adjust their approach if they receive new information or feedback from customers or stakeholders. This results in faster turnaround times and a more responsive development process which is essential for creating high-quality software that meets the needs of the end users.

There are several Agile methodologies that teams can choose from to develop software in a more flexible and iterative way.

  • Scrum: This is perhaps the most popular Agile methodology. It involves a small team of developers working together in short sprints to deliver a working product incrementally. Each sprint typically lasts for 2–4 weeks.
  • Kanban: This methodology focuses on continuous delivery and improving workflow efficiency. Work is broken down into smaller pieces and tracked on a visual board, and team members pull work items as they are ready to work on them. If you’ve used a Trello board before, then you know exactly how this works. Other apps, like Notion, offer similar features.
  • Extreme Programming (XP): XP is a methodology that emphasizes software quality and customer satisfaction. It involves practices such as pair programming, test-driven development, and continuous integration.
  • Lean Development: This methodology aims to reduce waste and increase efficiency in the development process. It involves continuous improvement and a focus on delivering value to the customer.
  • Crystal: This methodology is designed for small teams working on projects with a high degree of uncertainty. It involves frequent communication, regular feedback loops, and an emphasis on collaboration.

How Agile Methodologies Can Impact Code Quality

Code quality is one of the most essential aspects of any development process, as it directly impacts the success of any product. Agile methodologies have been designed to prioritize a customer-centric approach by breaking down features into smaller, manageable pieces of functionality. This allows for more frequent releases of working quality code that can be tested and reviewed to help deliver high-quality software that meets customer needs. Here are some practical ways in which Agile methodologies help promote and impact efficient code quality in development:

  • Prioritizing simplicity and efficiency.
    Agile methodologies prioritize simplicity and efficiency in software development. This means that developers are encouraged to write code that is not only functional but also easy to understand, test, debug, maintain, and modify. The goal is to create a codebase that is clean and simple, which can help reduce the potential for bugs and errors.
  • Encouraging modularization.
    The Agile process promotes the modularization of code. By breaking code down into smaller, modular components, developers can create code that is more flexible and reusable. This can save time and effort in the long run by reducing the need for repetitive or verbose code. Additionally, by optimizing the performance of each component, the developer is able to reduce the overall processing time, resulting in a more efficient codebase, breaking down features into smaller, more manageable pieces — often referred to as user stories or epics. This approach allows development teams to focus on delivering small, working pieces of functionality that can be tested and validated before being integrated into the larger codebase while also enabling them to respond quickly to changing requirements or feedback.
  • Improving readability.
    It’s important that code is legible and understood across the team, as it affects not only the developer who wrote the code but also other developers who may need to modify or maintain the code in the future. Agile methodologies help developers focus on writing code that is self-documenting and easy to understand by promoting the use of clear and concise coding practices such as self-descriptive naming conventions and avoiding complex code structures.
  • Test-Driven Development (TDD).
    TDD involves writing tests for the code before writing the code itself, which can help ensure that the code is well-structured and easy to read. This method emphasizes continuous feedback and improvement on the code, as developers are regularly provided with feedback on their work and have opportunities to make improvements as they go. By receiving feedback early on in the development process, developers can address issues and make changes to their code before they become bigger problems.
  • Continuous integration.
    This is a development practice that involves frequently integrating code changes from multiple developers into a single shared codebase. With continuous integration, code is automatically compiled, tested, and validated, which helps to catch issues early on in the development process. This approach ensures that code is always in a releasable state, which ultimately helps to improve code quality and reduce the risk of bugs or errors.

Overall, Agile methodologies can help developers write better code by promoting continuous code feedback and improvement while prioritizing simplicity and efficiency. By following these principles, developers can create code that is more efficient, maintainable, and robust, ultimately resulting in a better end product.

Key Principles Of Agile Development

At its core,

Agile methodologies value individuals and their interactions over following strict processes and tools.

This means that communication and collaboration between team members are prioritized to ensure everyone is working towards the same goals.

These processes are governed by a set of guiding principles that help the development team to create software that is tailored to the customer’s needs while ensuring high-quality delivery.

  • Customer satisfaction is the top priority.
    The goal of Agile development is to create software that meets the needs of the customer. This means that the customer is involved in every step of the process, from planning to testing.
  • Teamwork is essential.
    Cross-functional teams that work together to complete tasks are a core principle. This means that everyone on the team has a role to play, and everyone works together to achieve the same goal.
  • Flexibility is key.
    Everything about Agile development is designed to be flexible and adaptable. This means that the team can change course if needed, and the development process can be adjusted based on feedback from the customer.
  • Communication is critical.
    Open and honest communication between team members and the customer is encouraged. Everyone should feel empowered to share their ideas, concerns, and feedback.
  • Iterative development.
    Agile development involves breaking the development process down into smaller, more manageable pieces. By working on one sprint at a time, the team can make progress quickly and efficiently.
  • Continuous improvement.
    This means that the team is always looking for ways to improve the development process and make it more effective.

Prioritizing Collaboration And Communication

Effective collaboration and communication are crucial in any team-oriented project, and Agile methodologies place a particular emphasis on these values.

Prioritizing collaboration and communication ensures that everyone involved in the project is working towards the same goals and that any issues or concerns can be addressed quickly and effectively.

When collaboration and communication are prioritized, team members are encouraged to share their expertise and insights, which can lead to more creative and innovative solutions.

In an Agile environment, team members work closely together, and there is often a high level of interdependence between different areas of the project. If one team member is struggling or working in isolation, it can have a ripple effect on the rest of the team and ultimately impact the success of the project. Collaborating with other developers can help identify issues in the code that may not have been noticed otherwise. For example, another developer may notice a potential security vulnerability or identify a bug the original developer missed. Here are some of the key ways to ensure this:

  • Encourage cross-functional teams.
    Bringing together individuals with different skills and expertise can lead to stronger communication between business owners and the technical team that produces the product. I remember a time when I was working on a project with my team, and we divided the work based on each person’s strengths. This approach allowed everyone to contribute their best work to the project.
  • Break down silos.
    Silos refer to a situation where different teams or departments within an organization work in isolation from each other, without much communication or collaboration. Silos can lead to several negative outcomes, such as a lack of transparency, duplication of effort, and a slower development process. Eliminating barriers between individuals and teams would help foster collaboration by allowing individuals to share their skills and expertise.
  • Hold regular check-ins and feedback sessions.
    Scheduling consistent check-ins and feedback sessions can help ensure everyone is aligned on priorities and goals. I’ve found that this approach helps keep everyone motivated and focused on the end goal.
  • Use proper communication channels.
    Utilizing appropriate communication channels can increase the transparency and visibility of the project. In my experience, using tools like instant messaging (like Slack) and video conferencing (like Zoom) has helped facilitate collaboration and information sharing, particularly in a remote team environment.
  • Hold dedicated “Ask Me Anything”(AMA) sessions.
    AMA sessions can help frontline managers understand the rationale behind the approach and become comfortable with empowering their teams and giving up control. I remember a time when my team participated in one of these sessions, and it helped us better understand the benefits of Agile methodology because it put everyone on the same page and made everyone more confident in the overall direction.

Failing to prioritize collaboration and communication can have serious consequences for an Agile project. Miscommunications and misunderstandings can lead to delays, missed deadlines, and even project failure. Team members may become demotivated or disengaged if they feel they are working in isolation or not being heard. In the worst-case scenario, the lack of collaboration and communication can lead to a breakdown in the project team, which can be difficult to recover from.

Refactoring And Code Reviews

Refactoring refers to the process of improving the internal structure of code without changing its external behavior. It is done to enhance code readability, maintainability, and performance. On the other hand, code review is the process of examining code to identify issues or defects that may affect its quality, security, or functionality.

Refactoring

Refactoring is the process of restructuring existing code without changing its external behavior. It should be done frequently in Agile projects — often in the middle of a sprint — to keep the codebase clean and avoid technical debt. Here are some steps on how to carry out refactoring in Agile:

  • Identify the parts of the codebase that need refactoring.
  • Discuss with the team why refactoring is necessary and the benefits it can bring.
  • Prioritize the refactoring tasks based on their impact on the project.
  • Break down the refactoring tasks into small, manageable chunks.
  • Refactor the code while ensuring that it still passes all the tests.
  • Get feedback from the team and stakeholders on the refactored code.

Code Review

A code review is a process of systematically reviewing the code written by other team members. It aims to improve the code’s quality, find bugs, and ensure it adheres to coding standards. A code review should be done early and often in Agile projects to ensure that the codebase is always of high quality. Here are some steps on how to carry out a code review in Agile:

  • Assign a team member to review the code written by another team member.
  • Review the code for readability, maintainability, and adherence to the coding standards.
  • Provide feedback on the code and suggest improvements.
  • Discuss the feedback with the code author and come up with a plan to address the issues.
  • Make sure that the code changes are reviewed again after they are implemented to ensure that they meet the desired quality standards.

Overall, refactoring and code review are essential practices in Agile methodologies that help ensure the code is of high quality and meets the customer’s needs. By incorporating these practices into the development process, the team can improve collaboration, reduce technical debt, and deliver high-quality software faster.

Agile Compared To Traditional Workflows

Traditional workflows refer to development methodologies that follow a linear, sequential process, where each phase of development must be completed before moving on to the next phase, with a focus on ensuring that all requirements are clearly defined before development begins. Some examples of traditional workflows include the Waterfall model, the V-model, the Spiral model, and the Rational Unified Process. These methodologies are often referred to as “plan-driven” or “heavyweight” methodologies, as they involve extensive planning and documentation upfront, with less flexibility for changes during the development process.

Take a look at the Waterfall model, for example. This model, also known as the “classic life cycle model,” is based on a series of well-defined phases, with each phase depending on the successful completion of the previous one.

The phases of the Waterfall model typically include requirements gathering, design, implementation, testing, deployment, and maintenance. Once one phase is completed, the next phase begins, and there is no going back to the previous phase. This means that the Waterfall model follows a “top-down” approach, where each phase is dependent on the previous phase’s success. And, true to its name, the process resembles a waterfall.

One of the key characteristics of the Waterfall model is that it is heavily focused on planning and documentation. Before the development team begins coding, the project requirements and design specifications must be fully documented. This documentation is then used to guide the entire development process.

While the Waterfall model has been a popular development process for many years, it has several limitations. For instance, the linear and sequential nature of the model can be inflexible, making it challenging to incorporate changes and feedback throughout the development process. It also puts a lot of emphasis on up-front planning, which can be time-consuming and costly. Plus, we all know that even the best-laid plans don’t always go right.

As a result, many software development teams have shifted towards using Agile methodologies instead of the Waterfall model. Agile methodologies offer greater flexibility and collaboration, enabling teams to adjust their approach as they gather feedback and insights throughout the development process.

Here are some key differences between Agile methodologies and traditional workflows:

Agile Traditional
Flexibility Flexible and adaptable. Rigid and structured.
Customer involvement Prioritize customer involvement and feedback throughout the development process. Limited customer involvement, with the customer being presented with the final product at the end of the process.
Team structure Cross-functional and collaborative. Specialized and isolated.
Testing Occurs throughout the development process. Occurs the end of the development cycle.

While traditional workflows may have some advantages, such as providing a clear roadmap and a structured approach, I believe Agile methodologies are better suited for today’s fast-paced, ever-changing software development landscape. Agile methodologies offer the flexibility and adaptability necessary to meet changing requirements and deliver high-quality software products.

Conclusion

In conclusion, adopting Agile methodologies can have a significant positive impact on code quality. By prioritizing collaboration and communication, implementing test-driven development, and regularly conducting code reviews and refactoring, development teams can ensure that the code they produce is high-quality, maintainable, and meets the customer’s needs.

It’s worth noting that Agile methodologies are not without their challenges, such as the potential for scope creep. You can imagine how a flexible process that encourages frequent collaboration and feedback could lead to a project growing more legs than it needs. That said, Organizations that have adopted Agile methodologies report higher levels of customer satisfaction, faster time-to-market, and overall improved project success rates. As the industry continues to evolve, it’s likely that we will see more and more organizations embrace Agile methodologies to improve code quality and project outcomes.

Further Reading On SmashingMag

Categories: Others Tags:

How To Create Custom Illustrations For Your Website?

May 25th, 2023 No comments

Gone are those days when you only needed to put blocks of text on your website and expect a boost in engagement rates. People are becoming more graphics-centric and believe it should be an integral part of every marketing stage.

That’s where illustrations come in. They are powerful visual elements that you can employ on every aspect of your website – homepage or blog posts. 

According to Springer, customers guided by texts and illustrations perform 323% better than those without. This is especially true if the illustration is placed on your sales page and places where you need to nudge your customers down the conversion funnel.

Note that an illustration can simply be a work of art with characters depicting your brand process. It can also be a combination of data visualizations created with geometric shapes and is useful for articles.

In this article, we will discuss ten important steps that will help you create a cutting-edge illustration.

10 Steps To Create Custom Illustrations For Your Website

Creating a custom illustration for any page on your website is a no-brainer, but you need a basic knowledge of how designs work. So it’s advisable you go through a few tutorials on Youtube to help you get a good feel of how things work. 

Regardless, we have simplified ten basic steps that will help you create awesome illustrations as a beginner or pro below.

  1. Finding The Right Tools

There are several tools for creating illustrations, but the best picks on our list are Adobe Illustrator (AI) and Procreate. AI is a vector-based design software that you can use to design logos, fliers, prints, infographics, and illustrations. And designers sometimes use it to convert raster-based images to vector-based art and vice versa.

Procreate boasts similar functions to AI, such as logo designs and illustrations. You can use Procreate to design artwork, including 2D and 3D characters, which are helpful for storytelling on your home and sales page. Additionally, you can get resources like anime and manga brushes for Procreate from platforms like Brush Galaxy, which makes the tool even easier to use.

  1. Brainstorm A Concept

Once you have a preferred tool, it’s time to brainstorm a concept. You should have a clear picture of how you want your illustration to look, what it should contain, the colors, fonts, and the message to pass. On a better note, you should first identify what page of your website you’re designing the illustration for.

If you’re creating one for your homepage, then you’re most likely going to be working with stats like previous sales data, completed projects, and many others. In some cases, it could be character or descriptive art, which is often useful for impressing new visitors to your website.

A blog post usually does not need overly complex visuals. So your illustration might just wrap around a single paragraph, statistics, or fact. The same goes for case studies and newsletters.

When you’ve figured out what type of illustration you need, visit sites like Pinterest for variations of your concept. Filter the results to get relevant ideas and visuals. You can also explore Canva’s library and Freepik for more.

  1. Sketch Out Your Idea

Don’t forget to sketch the ideas you’ve just brainstormed. Concepts are very volatile, and it’s quite easy to forget one or two at every click. If you have an iPad, you can download Procreate and use your pen to quickly create a rough prototype. Alternatively, you can do the sketches on a sheet of paper – anyone works.

Note that you’re not replicating the same concepts you’ve seen from other designers. You are only taking inspiration from their illustrations to create yours. So take note of the possible variations that can give your own design a unique look when sketching.

  1. Set Up Your Workspace

The workspace is where all of your designs take place. To enhance your productivity and creativity, you should put all the necessary elements here. For example, you can line up your color palettes on the left for easy access when you’re creating your illustrations. This saves you the stress of going to the color drawer over and over again.

Other things to include in your workspace include your preferred shapes, quick boxes, images, and the texts you will use. Another way to tweak your workspace is by adjusting the existing preferences.

  1. Start Designing

Now that you have your sketches, you can scan and upload them to Adobe Illustrator. Start by tracing out the sketch lines and get a basic shape in place. You only need to create a gray draft before adding colors and other elements.

Adobe Illustrator has a font-matching feature that comes with Adobe Sensei. Use it to dig out the best fonts and strokes to use for your texts.

  1. Work With Geometric Shapes

Geometric shapes include rectangles, squares, circles, and stars. Often, most non-sketch illustrations start with these shapes and are further combined to create more complex designs. For example, you can use Adobe Illustrator’s “distort and transform” tool to bloat and pucker your shapes for a more artistic look.

When creating illustrator charts for in-article use, you can work with rectangles for the bar and circles for pies. 

  1. Prioritize Brand Consistency

Brand consistency means presenting your brand across all channels the same way. The importance of brand consistency is instant recognition. And that means anywhere your customers or previous website visitors see your designs, they know it’s you.

A quick way to implement consistency is by creating a reusable template for your illustrations. You should also maintain the colors you use, your inscriptions, the logo, and the design pattern. 

  1. Go 2D And 3D If Necessary

While most illustrations are already pretty good without adding extra aesthetics, they don’t have to look paper-like or rigid. For more realistic and expressive designs, you can use tools like Procreate and Adobe Illustrator. 

Also, note that not all of your illustrations need to be 2D and 3D. For example, illustrative pie charts and statistics for email content should be as simple as possible. Blog illustrations can take it an inch further and go 2D. 

  1. Review And Edit

Once your illustrations are ready, sleep on them and review them for extra details. You should also test them across different devices and screens. Importantly, your file size matters a lot since they will be going live on your website. 

So ensure you optimize each byte without affecting the illustration’s quality while also prioritizing your page-load speed.

  1. Use Pre-built Templates

Instead of creating everything from scratch, you can alternatively use pre-built templates. Some sites like Freepiks offer both premium and free templates which you can edit. All you need to do is insert your data where necessary.

If you are a bit versed in graphic designing, you can do some tweaking to the colors, shapes, and other elements used. 

Conclusion

Illustrations are so important and almost indispensable if you want to create a quality experience for people on your website. Adding them to your blog posts is even more crucial and can help enhance engagement.

To create a custom illustration, you need to brainstorm and sketch a concept. Afterward, open up your design software and set up the workspace. Scan the sketch and start designing. Finally, add the finishing touches.

Featured Image by upklyak on Freepik

The post How To Create Custom Illustrations For Your Website? appeared first on noupe.

Categories: Others Tags:

How a Business Idea Generator Can Help You to Turn Your Dreams into a Successful Startup?

May 23rd, 2023 No comments

The entrepreneurial landscape is awash with potential, yet one of the most significant challenges entrepreneurs face is identifying a viable, market-ready business idea. 

This is where a Business Idea Generator comes in. It’s a tool or service, often AI-powered, that provides novel business ideas based on specific parameters like personal interests, industry trends, and market gaps. 

As an aspiring entrepreneur, leveraging such a tool can be pivotal in transforming your dreams into a successful startup.

What Refers to a Business Idea Generator?

A Business Idea Generator uses advanced algorithms, industry data, and sometimes, human intuition to generate a list of potential business ideas. These generators come in several forms:

  • AI-based generators: These leverage machine learning and big data to produce business ideas based on trending market needs and gaps.
  • Human-curated idea generators: These are often platforms where experienced entrepreneurs share unique business ideas based on their experience and market understanding.
  • Industry-specific generators: These generate ideas within specific industries, taking into account the unique dynamics and trends of the selected field.

However, using a Business Idea Generator is not without its pros and cons. On the positive side, these tools can inspire creativity, provide a wide range of options, and save time. 

On the downside, the ideas generated may lack originality, and there’s a risk of receiving an idea that’s not a good fit for your skills or interests.

The Role of a Business Idea Generator in a Startup Journey

Business Idea Generators can be instrumental in various stages of a startup journey. They spark creativity and innovative thinking, helping you to think outside the box and explore areas you may not have considered. 

By offering a variety of unique business ideas, they open up opportunities for niche markets and innovative solutions. 

Some successful startups, such as “Airbnb” and “Uber”, were born out of unconventional business ideas that addressed a specific market need.

Turning Your Dreams into a Business Plan with a Business Idea Generator

Turning your dreams into a successful business involves more than just having a great idea. Here are some steps to follow:

  • Use a Business Idea Generator: Input your interests, skills, and market trends you’re curious about.
  • Evaluate the ideas:* Not all generated ideas will be perfect. Evaluate them based on feasibility, your passion for the topic, and market demand.
  • Select the best idea: Pick an idea that aligns most with your dreams and seems viable in the current market.
  • Validating Your Generated Business Idea

After generating and selecting an idea, the next crucial step is validation. This involves confirming that your idea is not just good but also has a real demand in the market. Here are some methods of validation:

  • Market research and competitor analysis: Understand the market size, customer preferences, and the competitive landscape.
  • Customer discovery and validation: Conduct surveys and interviews to understand your potential customers’ needs and responses to your business idea.
  • Minimum Viable Product (MVP) testing: Launch a basic version of your product/service to gauge customer reactions and gain feedback for improvements.

Moving from Idea to Execution: Building Your Startup

With a validated business idea, the next stage is to build your startup:

  • Develop a business plan: This should detail your business model, marketing strategy, revenue model, and growth plans.
  • Gather resources and form a team: Identify the necessary resources and the right team to bring your idea to life.
  • Seek funding: Depending on your needs, seek out investors, apply for loans, or bootstrap.
  • Launch and scale your business: Start small, measure progress, and gradually scale your operations.

Potential Challenges and How to Overcome Them

Despite its benefits, using a Business Idea Generator comes with potential challenges. You might end up with an idea that doesn’t resonate with your interests, or perhaps the idea is too broad, lacking specificity. Here’s how to handle these issues:

  • Lack of personal connection: If you don’t resonate with any of the generated ideas, don’t despair. You can always adjust and tweak the ideas to better align with your passion and skills, or try using a different generator.
  • The broadness of idea: If the idea is too broad, take time to refine and narrow it down. Focus on a specific target market or niche to make your idea more precise and actionable.

Do’s and Don’ts of Using a Business Idea Generator

As you navigate the entrepreneurial journey, a Business Idea Generator can be an invaluable tool. However, it’s essential to use it properly to maximize its benefits. 

Here are some do’s and don’ts when using a Business Idea Generator:

  • Do’s:
  1. Do consider your interests and skills: While the generator may offer a promising business idea, it must align with your passion and skills to increase the chances of success.
  2. Do validate the idea: No matter how good the idea seems, always validate it through market research and customer feedback before investing time and resources into it.
  3. Do be open-minded: An idea might seem outlandish or far-fetched at first, but with a little creativity and ingenuity, it could turn into a successful venture.
  4. Do use it as a starting point: Use the generated ideas as inspiration and tailor them to suit your vision and the needs of your target market.
  • Don’ts:
  1. Don’t blindly follow the generator: Remember, it’s a tool to spark inspiration, not a definitive guide. Always use your judgment and intuition.
  2. Don’t ignore market trends: While considering the generated ideas, keep an eye on market trends and demands to ensure your business idea has potential for success.
  3. Don’t rush into execution: Take your time to evaluate and refine the idea, build a robust business plan, and gather necessary resources before jumping into execution.
  4. Don’t neglect the competition: Even a unique idea can face competition. Research your competitors to understand their strategies and identify ways to differentiate your business.
  5. Don’t forget about scalability: Choose an idea that not only fits your immediate goals but also has the potential to grow and evolve with time.

Conclusion

In conclusion, a Business Idea Generator can significantly influence your startup journey. It can stimulate creativity, help identify unique opportunities, and accelerate the ideation process. 

While it has its challenges, with careful usage and by complementing it with personal intuition, market research, and validation, it can indeed turn your dreams into a successful startup.

Remember, an idea is just the beginning. It’s the execution of the idea through a well-devised plan that ultimately determines the success of a startup. 

So, use a Business Idea Generator as a launching pad, but rely on your skills, perseverance, and adaptability to navigate the entrepreneurial journey ahead.

Featured image by Lala Azizli on Unsplash

The post How a Business Idea Generator Can Help You to Turn Your Dreams into a Successful Startup? appeared first on noupe.

Categories: Others Tags:

Smashing Podcast Episode 61 With Rachel Andrew: What Is Web Platform Baseline?

May 23rd, 2023 No comments

In this episode of The Smashing Podcast, we’re talking about Web Platform Baseline. What is it, and how can it help determine your browser support policy? Drew McLellan talks to expert Rachel Andrew to find out.

Show Notes

Weekly Update

Transcript

Drew: Shes a web developer and technical writer and editor. Shes currently working for Google on the Chrome team where shes a staff technical writer and content lead for web.dev and developer.chrome.com. Prior to Google, she spent 20 years as a freelancer and business owner and shes written almost countless books and articles where she excels at taking complex technical subjects and making them more readily understandable. Shes also an experienced conference speaker, able to deliver a technical talk to teach an audience about CSS layouts or a keynote to inspire them drawing from her wealth of experience developing for the web. So we know shes an experienced technical writer, teacher and developer, but did you know she once taught a Canada goose to make a bourbon cocktail? My smashing friends, please welcome back Rachel Andrew. Hi Rachel, how are you?

Rachel: I’m smashing.

Drew: Welcome back to the podcast. Its been a couple of years and theres been a change of day-to-day role for you.

Rachel: Yes, yes. I guess last time I was here it was mid pandemic and I was still editor-in-chief of Smashing Magazine and yes, these days I’m over at Google on the DevRel team with my content team sort of helping to get good docs and information out to our developers about things on the web platform.

Drew: So still in the realms of helping people learn about the web platform and assisting their busy lives, trying to keep a pace of all the new technologies and developments?

Rachel: Yes. Yeah, its kind of a perfect role for someone who spent most of their life sort of explaining things to web developers. So yeah, its great and within a really great team of people who were very dedicated to talking about all this new stuff.

Drew: So speaking of new developments and also Google, last week was Google I/O 2023, which is always an exciting time for us tech nerds because there are all sorts of announcements and updates from Google. With Google being such a large contributor to the web platform, it then becomes an exciting time to see whats been worked on for the web in particular and see what might be coming out next. I feel like we’re in a place with a web platform where its continuing to develop a fantastic pace at the moment.

Rachel: Yeah.

Drew: Those of us who have been working in the industry for a while remember the years when nothing was added in terms of browser capabilities, I mean sometimes years at a time. You were working on the web back then. Was it frustrating that things weren’t getting added or did it just make it easier to keep up?

Rachel: I think it was frustrating. You know, when we had, we had five years between IE6 and IE7 so that was kind of five years that the web platform just basically stopped because so many people were using IE6, although there were new other browsers around you couldn’t really use all the new stuff that they were putting into the browser because the majority of people coming to your website were in a browser that didn’t support it. So I think it was very frustrating because thats a very, very long time, especially when IE6 had all sorts of bugs and issues as well so that we weren’t getting fixes to things.

Rachel: It wasn’t even new features. We were dealing with problems, like bits of your content disappearing for no apparent reason. So yeah, it was frustrating, but it was very stable. Buggy but at least the bugs that we could list them, there were websites that listed all of the IE6 CSS problems, so you’d hit one and you’d be like, oh yeah, thats that. I know how to fix that. So we all became pretty expert in dealing with browser bugs basically and knowing what they were.

Drew: I remember things like Peekaboo, was it Peekaboo bug was that era.

Rachel: Yes.

Drew: And what was the website that listed them, listed them all? I can’t remember its name now, but the list of known bugs just got longer and longer and longer over time to the point where it became difficult to find the one you were, the particular bug you were experiencing because the list was so long. We were in a place back then where the dominant browser, which was Internet Explorer at the time, was the browser that was seeing the least technical innovation but that doesn’t mean there was no technical innovation because there was a broader ecosystem, but was it ever possible to use new bits of CSS that were appearing in things like Firefox? Is that something we could do when the dominant browser was so far behind?

Rachel: It was pretty hard. I mean, I think all the ideas of things like polyfills and also there was a lot of us kind of pushing the progressive enhancement story as well and saying, look, its fine, your website doesn’t need to look the same in all browsers. I think I’ve been saying that for most of my life at this point. And that was a big thing at the time because people were just sort of A/B test in the browsers, you know, there was no… you’re sensing off to your client and they would just open it in another browser and be like, “Oh no, this is wrong ’cause its three pixels out on this other browser.”

Rachel: And that was very, very common. People would talk about pixel perfect and what they would typically mean is it should be exactly the same as the PDF or whatever that you were working from or the Photoshop file and all of the browsers that they were aware of, or at least both browsers typically. So I think it was quite difficult to push the web forward at the time, you got quite a lot of resistance and you’d often have to just do it anyway and hope you’d get away with it quite a lot of the time.

Drew: We don’t seem to see that so much these days where clients or anyone really is looking at a web experience side by side in two different browsers and saying, oh, they’re not quite the same. Is that because browsers are much more standardized now and they do look the same or have the expectations changed, do you think, because of so many devices that we’re looking at, the fact that mobile devices and tablets and so many different screen sizes that has that expectation gone away?

Rachel: Yeah, I think its a bit of both, isn’t it? I think the web browser is how we do everything these days and its less of a separate bit of software, its just kind of how you use your computer and a lot of the time and I think theres less of an awareness of, oh, we should be checking this for someone who isn’t a developer, we should be checking this in the different browsers. Far more likely, I think, would be someone saying, “This doesn’t work well on my phone.” ‘Cause they’ll get the email saying, oh look at the new site, and they’re probably on their phone when they get that email and they’ll open it on their phone and then they find, oh, somethings overlaying something or its hard to get to something because of a toolbar or whatever.

Rachel: So I think its far more likely that a client is going to be coming back with that kind of problem. Maybe they’ve got an older version, an older phone that they’ve not updated and its got an older version of software on it or whatever than doing that kind of desktop A/B testing that used to be really common, even with a fairly non-technical client, they would’ve been told by someone that they should make sure it works in these browsers and so they would be doing that checking.

Drew: Yeah, I mean clients would come along to those of us who are building sites for them and they would say, right, we need this site built and it needs to work in IE6 or it needs to work in IE7 and they’d have these very definitive browser versions that things had to work in. And now between, as you mentioned, between IE6 and IE7, there was a multiple year gap, so that constraint from the client could have, it could massively impact your sort of choice of technology or design, couldn’t it?

Rachel: Oh, absolutely. Yeah, I mean that was just sort of fairly standard when you were building sites and at the time I was building sites for clients that would be on the spec for the site would be which browsers that you had to support and you would be expected to test it in those browsers and if it worked in those browsers, that was all good. That was the line that you were following.

Drew: Yeah, I guess even things, even that things were pretty limited. It was a fairly easy decision to make to say these are the browsers that we’re supporting. Its got to work in IE7 for whatever reason.

Rachel: Yeah.

Drew: It was fairly clear cut, but these days I don’t think I could even tell you what version of Chrome or Firefox or Safari I’m running or if thats the latest, I’m presuming its the latest, but its not so clear cut and straightforward now, is it?

Rachel: Right, yeah. You don’t even notice that the things update. They just update and you don’t realize if thats a major version or just some say security release thats come out that you need to update to. I don’t think most people know which features landed in which version of a browser. We used to know. We used to know exactly what was available in each browser, so it’d be like, “Oh great, this project is IE8 and therefore I’ve got, I don’t know, display table” or something that landed in that browser.

Rachel: We used to know. These days we don’t know. I know I spend all of my time documenting this stuff and writing about whats new in the web platform and even so, I’m fairly hazy. If you said to me, “Oh, what was in Chrome 113?” And I’ve just done the work on that, I’d be like, “Err, was that in that one or was that in the beta?” So the average developer then you’re not going to be able to keep track of all that stuff. Theres so much stuff landing all the time.

Drew: So it makes the situation quite difficult, doesn’t it, when you might have sometimes contracts with people you’re building stuff for and certainly expectations that theres going to be a level of browser support but its not, if you don’t know what versions things are and they move really quickly, it can be really difficult to pin down to a targeted browser version. And this is, I believe its the crux of the problem thats addressed by one of the big announcements at Google I/O. How do we figure out whats safe to use?

Rachel: Yeah, and so this is something we’ve been thinking about actually for as long as I’ve been at Google is we’ve been thinking of this top pain point that we hear from developers that they struggle to keep up with the web platform and they struggle to know what is safe to use, what is okay to roll out in production without worrying about it. Typically developers will be building for the latest versions of a site and then suddenly they’ll realize that, oh, this is broken over here and they just don’t, they didn’t realize that and to actually figure out the browser support involves going kind of property-by-property, feature-by-feature to say, can I use our MDN and looking at the compatibility data. Its all out there, but you have to do that on a feature-by-feature basis.

Rachel: And so we’re kind of thinking about this issue and it always comes up, we talk to a lot of developers and it always comes up as the top problem and so we’re thinking about how we can resolve that. And thats what kind of came to this idea of, well, can we create this line and say that everything thats passed this line has interoperability, is kind of safe to use without worrying about it. And thats where this idea of Baseline came from, to have this kind of moving line that includes all of the features that are interoperable and don’t have any major standout issues. And thats what we’re calling Baseline.

Rachel: And the whole project is its not just a Google thing, this comes from the Web DX community group. So we’re working with other browsers and other people on defining this and kind of coming up with the feature groupings so that we can try and create this clarity for developers that they’ve got a sort of line where they can say, they can look at that and say, oh yes, this thing is in Baseline and therefore I know its going to work everywhere in the most modern browsers.

Drew: So instead of saying this, we’re supporting these particular browsers, you’re saying this is a core feature set thats common across all the currently available browsers. This is a safe set of features and its that set that I’m going to be developing for compatibility with.

Rachel: Right, yeah. And that sort of takes that requirement to figure out each individual feature for, and also because we get partial implementations of stuff all the time on the platform and its like, so the kind of feature grouping part of this, it is the big piece of work really to actually identify, does the feature completely work everywhere because sometimes there will be support for things. I think one of the things that, an obvious thing that people understand is the gap property in where in Flexbox and Grid and so on. Now you could test for that. You could test for where the gap was supported and a browser would say yes because it was supported in grid layout even when it wasn’t supported in flex layout and therefore there was no way to check for this. And it was quite confusing for people if they were just doing that test. So I think theres these sort of groupings of things is also quite useful. So the things that are in Baseline are things that do work as a feature, even if that does actually involve various moving parts.

Drew: Yes, because theres been a trend from the sort of latest CSS specs to be, whats the word, sort of unifying some of the properties isn’t there rather than-

Rachel: Yes.

Drew:span> … rather than having individual properties that do the same thing in different context, using the same-

Rachel: Right.

Drew:span> … keywords across different uses.

Rachel: Yeah, so things like alignment, fragmentation, we’ve got these specifications that deal with sort of alignment across all of the different layout specs, which is great because it means that say if you want to switch from a flex to a grid layout or whatever, all the alignment stuff should work in the same way, but does mean that we potentially get these partial implementations and thats quite difficult to understand. So yeah, I think its things like that and so that theres an awful lot actually goes into the creation of this sort of feature set grouping and we’re not all the way there yet. We’re hoping to get most of CSS and JavaScript done by the end of the year because its actually quite a job just to figure out how things all fit together.

Drew: So its almost like instead of targeting a version of any particular browser, we’re targeting a version of the web platform. We’re saying-

Rachel: Yeah.

Drew:span> … look at the web platform as it is here today, these are the things that are universal, that are reliable to use and thats what we’re going to support. And anything that falls out of that boundary included because the implementation might be patchy.

Rachel: Right, yeah. It might need a bit more care. And its not saying to people, oh, you can’t ever use these things, but if you know its not in Baseline then maybe theres some things you need to think about there and it might be fine for your project or it might be that it has a good fallback or its something that is polyfillable but those are things that you do need to think about on a case-by-case basis rather than just, this should be fine to use.

Drew: I think most of us are familiar with sites like canIuse.com, which you mentioned briefly before. Is this just replicating information that already exists or is it different from can I use?

Rachel: I think its different in that, so something that can I use does, and also the MDN BCD data, they work very much on a sort of feature-by-feature basis. They don’t actually cover all of the web platform. Theres definitely, certainly Can I use has made some decisions in terms of how to group certain things. I have a long standing open issue to split out fragmentation from multicar for example, because they’re bundled together, making multicar look harder to use than it actually is because there are fragmentation bugs in there.

Rachel: So they’ve done some of the same stuff, but what we haven’t got there is this sort of full view of the platform and this idea of this is within Baseline, this is out, you still have to go to each thing and make those decisions. Ideally we’re hoping, I mean as MDN are using Baseline on feature pages, they’re rolling that out at the moment. Its probably saying that we’re hoping that Can I use, we’ll also be able to use and say, “Oh, this feature is in Baseline” as well as that more fine grained data.

Drew: And how do you make that decision to say that yes, this, not only is this supported but this is widely supported enough that we can include it in Baseline. How do you make that distinction?

Rachel: So at the moment we’re going back the last two major versions of browsers and theres been a lot of debate about that. As you can imagine. Its something thats great to [inaudible 00:17:38]. The fact is I think the line will always be wrong for if we say this is the line, two versions back, a lot of people are saying, “Oh, you should use minor versions of Safari” because we’ve seen some massive features going in doc releases because of the way that Safari do their versioning because obviously a main version of Firefox and Chrome, thats every month we’ve got a new main version. And so thats obviously up for debate. Some people are saying we should go further back. Other people are pointing out the fact that just because Chrome has updated, all of the browsers are derivatives that use chromium, they might not have updated. So I think the line will always be wrong, I think.

Rachel: But what it does give is this sort of stable view onto things. And the other thing that we’re planning to do as part of this is to have these kind of moments in time. So at the end of the year we’re going to say, right this cut is where we are at that point is going to be Baseline 24 and that will be a static line. That will be whats in Baseline at this point in time. And then in a years time we’ll do Baseline 25. And I think an interesting thing then will be the difference between those two points because I think a conservative web team could say, “Right, I am sticking with Baseline 24” even though maybe they’re well into 25, we’re sticking with this.
But the things between those two lines then I think become the things that you might want to make judgments on rather than having to look at the entire web platform and say, “Oh, can I use this? Can I use that?” And say, “Well, we’re going to use this yearly cut of Baseline.” And then the things that came after that that are in Baseline as it moves forward we’ll take a look at and see, oh, I can polyfill that or this is fine as a progressive enhancement.

Drew: It puts me in mind slightly of things like Ubuntu Linux distribution and their long-term support releases that they do.

Rachel: Right.

Drew: They’ll say, “This is the one that we offer long-term support. Its stable, its reliable to use.” And so you might adopt that and that doesn’t mean that you wouldn’t necessarily install a couple of key extra, more frequently updated packages or whatever, but you know that the system that you’re working with is sort of frozen in time and supported and is a known quantity going forward.

Rachel: Yeah.

Drew: I guess those who work in very regulated industries who sort of frequently go under contract with customers or suppliers, whatever, to say they’ll provide compatibility with certain browsers as it is at the moment. Surely this would be a very welcome change because these are actually more concrete measures that support can be tied to and its a stability thats more in line with the stability of a binding agreement than an arbitrary version number that some nerd in Silicon Valley might attach to a build of a browser.

Rachel: Right.

Drew: So you can say our platform is targeting Baseline 24 and you could keep that way for three, four years maybe.

Rachel: Yeah.

Drew: And then review it and update.

Rachel: Yeah, I like that. I like that stuff, yeah, the idea, this is a sort of stable thing and I think that that yearly release will become, I think, quite important. So I think I can see libraries and frameworks and so on tying themselves essentially to a stable release, one of the yearly cuts and then moving on. And I think it should be really interesting as well being able to see, well actually how has the platform moved on between those two yearly points? We don’t really have a look at that at the moment. I mean you could work it out, but it’d be quite a lot of work. It’d be nice just to be able to see that and see how things are changing.

Drew: I always enjoy a list of features that are included in whatever. Heres things that you can use that you won’t, perhaps weren’t aware of. And I can see how a big list of Baseline features might highlight different things that an individual developer might not be aware of that-

Rachel: Yeah.

Drew:span> … have arrived on the web platform and are ready to be used.

Rachel: Yeah, I mean the awareness is a big thing. I mean, I’ve been doing, me and a colleague as well have been doing talks, whats new on the web platform type talks and typically introducing things that are interoperable. And every time there will be people saying, “Oh, I never knew you could do that”, or “I never knew that worked. I thought that was an experimental thing.” And then realizing that its actually a feature thats in all engines. And I think that thats very, very common. So I think thats the other sort of side of this is that it also raises awareness of features that now are interoperable, that people have got an idea that the web platform moves incredibly slowly.

Rachel: I think particularly people like us who’ve been doing this for a long time and remember those days. And so people are very surprised, you know, you still see people saying about a new feature, “Oh well it’ll be five years before I can use that.” And yet you’re looking at things like container queries and cascade layers. All of these things landed cross browser very, very quickly, which is great. And I think thats a story that this can help tell as well.

Drew: So this was a big announcement from Chrome at the big Google I/O conference, but you mentioned its not just a Google thing is it, there are other parties involved. So who is deciding whats in the collective Baseline? What parties are involved in this?

Rachel: Right, yeah, so I mean obviously we partnered very closely with Mozilla and MDN in launching this. So that actually during the developer keynote we launched this on web.dev and on MDN at the same time on a select number of pages because we haven’t got a full feature site yet. But it was nice to actually show what it would look like rather than it being a kind of theoretical thing. And also MDN published a blog post about it too and their thinking. But yeah, the work has been done within the Web DX community group and that group has representatives from all of the browsers and various other people including interested developers.

Rachel: Anyone can join that group and be part of those discussions. So thats where we’re also asking people to go and comment on this stuff rather than, I mean people are very welcome to come and talk to me about it, but in terms of getting sort of information out there and discussed by the wider group, raise issues on the Web DX community group site because thats where the people are who are making the decisions. And at the moment its just fantastic to be getting the feedback into that group so that we can actually see is this solving a problem, what problems maybe we’ve missed and be able to talk about that.

Drew: So its a broader community effort, but it just so happens that the major players Google, Mozilla and everything are putting a lot of time and effort into it and really backing it as an idea.

Rachel: Yeah, yeah. And I think thats something that as DevRel, you know, as developer relations, thats kind of what we do. We try and bridge the gap between browser engineers and spec writers and the developer community. And so I think thats something that we can do as DevRel for the web is to actually bring forward these things that we think might help and see where we can take them.

Drew: Now I’ve heard about the Interop 2022 and now 2023 initiatives. Does Baseline relate to Interop at all? Or maybe you could talk us through that where it fits in?

Rachel: Yeah, I mean its kind of the same group of people certainly as Google who are involved with those projects. So the Interop project takes a set of features that if its based on web platform tests, so it takes a set of features that have some sort of interoperability problem. So it might be that they don’t work in one or more browsers or they have sort of bugs that are causing pupil problems. So we’ve got this set of features and then over the year all of the engines work to implement or fix those things. So we’ve kind of got a score, a scoreboard where you can go and look and see how everyones doing.

Rachel: So the Interop project works to fix known issues, either make things interoperable or fix books and things that look on paper like they work, but have some sort of problems. And so that project is getting more things essentially into Baseline. So they’re linked in that way and they’re a lot of the very similar people are working together on those from the browsers. So I think in terms of the relationships there and the fact that Interop did bring, for the first time, all of the vendors together in this sort of common goal to make the platform better, theres definitely a link there in terms of this is what we care about. Whereas Baselines kind of from the other side, its saying, well, okay, what is there? What is interoperable? What can we already use? So yeah, hopefully things like Interop will help to add more things to Baseline as we go along.

Drew: So it is basically just identifying things that could potentially go into Baseline, might be nearly there, and then swarming on those features to get them across the line and get them interoperable and usable on the platform because they’re seen as important or significant in some way.

Rachel: Yeah, and I mean we know that that developers aren’t going to use things in general unless they are available across all engines. So its kind of in everyones interest to work together to get to that point because then people use the stuff that we’re building so that, yeah, its said so they kind of work very well together. And I think its just this sort of spirit of collaboration and trying to make things better for developers.

Drew: We’ve talked about how developers might target, in past, a browser version and now we’re saying would target Baseline, but it works the other way around, doesn’t it? If the frameworks and the tools that we are using as dependencies in our projects, they can also declare that as a level of support. Is that right?

Rachel: Yeah, absolutely. I think thats something that we’d love to see how a framework or whatever you could say, everything that is used by this framework is Baseline or is Baseline 24 or what have you. Thats going to give a lot of clarity to developers to not then need to fish around in the framework and find out what they’re doing to make sure ’cause if you’ve got to do a certain level of browser support in your project, you need to make sure that everything you use also has that level of browser support so that it could definitely make that a lot clearer.

Rachel: And I think also things like publishing articles. One of the things that frustrates people, and I know as someone who writes and edits a lot of content, is if people get halfway through an article and then they find something that is experimental or is so new or only works in Chrome or whatever, thats really frustrating because you think, oh, I’ve found the thing that helps me solve my problem. You’re working through it and then you’re like, oh, thats not coming ’til next year. And so have been able to put on an article, everything in this article is in Baseline. That gives you a lot of confidence to go forward. So I think theres lots of uses for this out in the community and thats something we really hope will happen, that just to give that kind of clarity to developers.

Drew: Its that last section of an article, isn’t it? You’re reading along about some interesting technology and then it comes to the section of how you might work around it for the browsers that don’t support it.

Rachel: Yeah.

Drew: I thought-

Rachel: Exactly.

Drew:span> … we were into a good thing here.

Rachel: Yeah, ’cause when you’re searching, you’re searching to solve a problem, things come up. Its very frustrating if you realize that its a year away or other browsers have said we’re not doing that or whatever, you know? So yeah, I think theres a lot of opportunities for clarity for people who are writing and for developers of libraries and frameworks to actually just make it very obvious to developers what the status is.

Drew: And things like WordPress themes for example, or any of these sorts of things where you’re taking somebody elses code and making it part of your project to know that what level of support in terms of web functionality is in that is invaluable. I guess it would make sense for things like tools that any tool that gives you code to embed into your site, be that a Stripe checkout or a live chat widget or any of those sorts of things, I guess it would make sense for them to declare their state of compatibility too.

Rachel: Yeah, yeah, its just kind of a shorthand. It saves you having to do all of that investigating for each thing that you use. And we know that every website these days has tons and tons of third party stuff in it. We’re not all sitting down with Notepad anymore and carefully crafting our websites. So I think anything that makes that easier and allows people to show the status of things is really helpful.

Drew: It actually is a really simple concept, isn’t it, to say heres the set of features, they’re well supported, we’re giving it a label, we’re documenting it. Its actually so simple, its really rather genius I think. Its some amazing work thats been done there by everyone involved.

Rachel: Yeah, I think it speaks to a lot of what I’ve thought about over many years in terms of that kind of clarity. And thats always been my thing is making things clear to people, making things seem straightforward rather than trying to make things complex. And so I really love being able to be involved with this and bring it forward.

Drew: The HTML spec for example has a process for an element or an attribute to be deprecated. So things get removed from the spec as they become obsolete or they’re replaced by a newer specification. Is it possible for features to drop out of Baseline once they’ve been included?

Rachel: It could be possible. Its one of the things we’ve talked about a lot. I think really the devil will definitely be in the detail with all this stuff. And thats one of the things is well what happens if something essentially gets broken? Maybe one engine does something which causes a problem with something. There is a possibility that yes, we’d have to remove something. Thats definitely something we’ve talked about. I mean hopefully browsers aren’t going around breaking stable features, but it is a possibility or something might get deprecated although we tend not to fully remove things from the web platform very often. Its more that we say, “Yeah, maybe don’t use this,” but there is a possibility that something that is in Baseline could start to have a problem because of something that one of the engines does.

Drew: I guess then thats one area where these sort of yearly cuts as you’ve described them, become sort of quite useful in that something might have appeared in Baseline 24 but then in Baseline 30 it might be gone and there is a way of having a distinction there.

Rachel: Yeah, and it would also highlight that stuff I think a lot more clearly than we have a way of doing at the moment because I think hard to know what things have actually been deprecated on the platform. A lot of things that are deprecated are things that are only in one engine and therefore would never have been in Baseline in the first place. But yeah, it is possible as things move forward that that would happen and it would make it clearer.

Drew: And such as the way of the web, we do deprecate things, but as you say, they don’t ever go away really.

Rachel: Yeah.

Drew: We don’t-

Rachel: I was just saying maybe don’t [inaudible 00:33:42].

Drew:span> … tend to remove things, you know, can still use the, I’m guessing you can still use HTML font tags because we don’t break things once they’re standardized.

Rachel: Yeah.

Drew: Even though nobody would ever recommend using them, they’re still going to work in your browser because sites have been developed to that standard and the browser-

Rachel: Yeah.

Drew:span> … will continue to support it. I guess, in a way, theres Baseline forms a little bit of a positive pressure. If a feature does get broken, then the fact that it was in Baseline and the whole community is relying on it being there is a factor in prioritizing what gets worked on by that particular maintainer of that browser engine. They’re going to see that, no, this is important, we need to fix it pretty quick.

Rachel: Yeah.

Drew: So hopefully its a sort of positive pressure in that regard. There seems to be so much really in development and coming to the web platform. Are there any particular things that you’re really looking forward to seeing becoming interoperable in the coming months?

Rachel: Yeah, I mean theres a bunch of interesting stuff. I’ve always been interested in the things that look at things that developers are already doing. So they’re using JavaScript to do it, or what have you, and then having them built into the platform because obviously things that are built into the platform we can build in things like accessibility and also performance. Things that tend to perform an awful lot better if they’re a built-in feature as opposed to being JavaScript on top. So theres sort of interesting stuff from the open UI group. The next thing that is about to land in Chrome is the Popover API. And of course popovers are something like everybodys building all the time.

Drew: Yeah.

Rachel: And I think a lot of these open UI things are very much those sorts of features that pretty much every developer, every front end developer has built on numerous occasions. And every front end developer has tried to solve the accessibility issues and the performance issues and the sort of weird bugs that come up when they interact with other things. And so the fact that these are getting actually built into browsers, I think, is very exciting because it just, its a bunch of work you don’t have to do and its probably going to have better accessibility and so on than most people are going to be able to manage for themselves and it gives something to build on top of as well, you know, can add things to them.

Rachel: So yeah, so I’m excited to see Popover and in a similar sort of vein is the work on scroll-driven animations because thats a thing that people like to do and is very hard to do well, you know, having things that animate on scroll and that, again, is something that is coming in. It should be in Chrome 115. So it’s, again, its these things that we’re doing on the front end of the web and we’re actually able then to build into the browser. I’m always very keen to see those ’cause I think they solve a lot of problems.

Drew: Yeah, definitely. I mean anywhere where a developer has to mimic something that you think is native browser UI and you’re trying to build it yourself, there are so many places to go wrong, aren’t there?

Rachel: Yeah.

Drew: If you’ve ever had any of your work through an accessibility audit, you know that its things like modal dialogues and all these sort of things that constantly will contain flaws that need to be addressed because theres just so many things to think about in terms of keyboard focus and clicking away and all these different subtleties that you need to make sure that you take care of, that is, as much as anything, as much as it being bad for accessibility, if you get it wrong, its a massive waste of time for all us developers doing this all ourselves over and over again when it just makes sense. Most apps will have some sort of modal or popover functionality. So yeah, it makes complete sense for it to be part of the platform implemented by the browser vendors in a way where its accessible and its just a good solid layer to then build on top of in terms of styling and yeah-

Rachel: Yeah.

Drew:span> … it makes total sense. Its a exciting way to see the platform go.

Rachel: Yeah and I think, because the other thing with everyone building their own thing is that a lot of people don’t build their own thing, they rely on a third party thing and quite often things people are relying on are actually really old and they haven’t been updated to, they might have issues with accessibility or whatever and they haven’t really been updated for more modern browsers. And so its sort of, I think the more that people can use whats built into the browser, the sort of better experience that the end user of the site is likely to have.

Drew: So your team at Google maintains a bunch of resources to help developers keep up-to-date with the web platform. What are those resources and where should people go to look and find things? What would they expect to find there?

Rachel: Yeah, so we’ve got web.dev and developer.chrome.com are our two sites that DevRel own. It used to be, back in the day, when I sort of arrived, there was a real mixture of things on each site and a sort of thing that was commonly said was that Chrome were using web.dev to pretend things that were only in Chrome were stable APIs, lets say I don’t think anyone ever intended to pretend that. I think there was just a slightly disorganized content strategy. So as kind of part of the preparation for Baseline, because I wanted to make sure that we could be clear because if we’re talking about developer clarity, its pretty bad if all of our stuffs in a mess. I started moving content. And so now, certainly all the newer content, there may be some older stuff that we haven’t tracked down, but the newer content, if you go to web.dev, you should really be seeing stuff about stable APIs.

Rachel: So things that are interoperable and also things that are coming onto the platform. I do a sort of whats new on the web platform that includes some new stuff from all engines. So that kind of looking at what the broader landscape is and also things like our best practices. So things like about performance, which while some of the tooling is Chrome-only, raising the performance of your site, it is going to help in all engines. So thats whats there on web.dev. So thats kind of the practical side of things. You’re building a website, you want some advice. Thats what we’re doing there. And I try very hard to make that about the web, not about Chrome and thats the sort of content there.

Rachel: But obviously we are a team thats supporting Chrome and supporting the things that Chromes releasing and so we do that over on developer.chrome.com. So thats going to be your new APIs. You want to find out about popover thats landing, there’ll be an article about that soon. So all the things that Chrome is doing for the web, essentially you can find on developer.chrome.com. So that will be experimental things or Chrome-only things, things that are Chrome-only for now, all that stuff is there. And I hope that brings a bit of clarity to our content and that we’re not trying to pretend anything. We’re just trying to be clear about what we’re doing and how well supported it is.

Drew: Great. So we’ve been learning all about Web Platform Baseline. What have you been learning about lately, Rachel?

Rachel: Theres always something interesting to learn about. I’ve done a couple of things. I’ve been learning Python because its a language that I, for whatever reason, never learned. I’ve learned various languages over the years, but I do less web development these days and more kind of comparing of data sets and Python is the language that a lot of that stuff is done in. So its quite fun to learn new language anyway and its useful for the sort of stuff I tend to find myself doing these days.

Rachel: And I’ve also been thinking a bit about the whole generative AI space and in particular as a content lead, how do we prepare our content to make it more useful to those kind of models because theres a lot of stuff about asking questions of a chatbot and so on. And so I’ve been kind of just starting to read around that subject a little bit and start to see, well, if we’re preparing content, how can we be making that more useful for that kind of thing and that interaction?

Drew: If you, dear listener would like to hear more from Rachel, you can find her on the web at rachelandrew.co.uk where you’ll find links to her socials, her writing and numerous other projects. And you can find her writing regularly about the web platform at web.dev. Thanks for joining us today, Rachel. Did you have any parting words?

Rachel: Let us know about Baseline. Comment and raise some issues, or just join in the chat on the Web DX community group, on the GitHub repo there. We’d really like to hear what you think. This is, we’ve been talking about it internally for a long time and so now we’ve got it out there and I think the work starts now and the discussion with the community starts now. And so we’re all very, very excited to read the feedback and find out what you think.

Resources

Categories: Others Tags:

15 Best New Fonts, May 2023

May 22nd, 2023 No comments
15 Best New Fonts, May 2023

The choices you make when selecting a typeface have more impact on your design than almost any other decision, so it’s good to have some options at hand.

Categories: Designing, Others Tags:

How On-Campus Housing Security Is Transforming Thanks to Technology

May 18th, 2023 No comments

For many, living on campus during college is an integral part of the university experience. Social engagement and academic sharing by living on campus enable students to enrich this period of higher education. Thanks to on-campus residence, students can access multiple educational extras including seminars, conferences and lectures, libraries, sporting activities, and university clubs. Communal living permits students to form lifelong friendships with peers and form closer relationships with faculty members.

Fortunately, residential technological advancements are not just limited to private residences, apartment complexes, or hotels. Now universities are integrating technological solutions into on-campus dorms to improve comfort, efficiency, and security.

Security is one of the principal concerns for parents when children leave for university. Violent crimes and mass shootings experienced across the nation at schools and on college campuses have shocked and worried families sending sons and daughters off to college.

Access Control for Increased Student Safety

Technological advances now permit the use of fobs, keypads, keycards, and mobile entry credentials. Keyless door locks now eliminate the need for students to carry keys or keycards. Doors can be opened using biometric scans or credentials in a smartphone app. This increases property protection, impedes unauthorized access, and significantly reduces the need to change locks because of lost, stolen, or misplaced keys. 

Access to common areas such as fitness centers, student lounges, study rooms, or pools can be equipped with secure entrance technology facilitating controlled entrance to all areas within on-campus housing facilities.

Technological security access systems also provide several other benefits such as logging who enters and exits a building and facilitating rapid entrance thanks to automation. 

Anomalies such as repeated use of entry credentials can be quickly identified and verified alerting university officials if access credentials have been stolen, cloned, or shared.

Cloud-based access control systems permit remote management from anywhere so that doors can be locked and unlocked at any time from anywhere eliminating the risk of students being locked out and vulnerable. 

Stolen credentials can immediately be disabled so that they cannot be used by bad actors. Credentials granted to service providers and maintenance professionals can be deactivated once tasks have been completed.

Security Video Monitoring

Campus security has always been a priority at educational institutions, but today’s generation of students has grown up in a world where video recording is the norm everywhere. This facilitates the use of video security monitoring within and around dormitory buildings. While privacy does remain a concern, pathways, parking lots, entrances, and exits that are a part of university housing facilities should all benefit from video security surveillance cameras with these areas benefiting from proper lighting. 

Now school video security monitoring systems integrate AI. This permits universities to use automation to monitor potentially suspicious behavior in real-time. Causes for worry can be identified rapidly with alerts sent to security personnel facilitating immediate intervention. Emergency responses become proactive instead of reactive. This greater level of monitoring helps to create a safer environment for students.

University dormitory administrators are also able to identify occupancy rates and times as well as usage patterns. This information can lead to better use of housing resources such as water and electricity increasing efficiency, reducing waste, and saving money.

Security video monitoring systems can integrate biometric facial recognition to improve access control efficiency and increase housing security. These systems can also be programmed to send security alerts informing residential managers and security personnel of a need for immediate intervention should unauthorized entrances be attempted, or suspicious behavior be detected.

Cloud-based video systems can permit security personnel or residential managers to view video feeds from school security camera systems remotely using mobile devices and video analytics can send notifications to security staff and local authorities.

Dorms Are Smarter

Thanks to greater connectivity, the IoT – Internet of Things together with machine learning algorithms and AI are able to collect massive amounts of data and analyze it in real time. Residential managers and building administrators can improve property management and services offered. For example, heating and cooling systems can be better managed thanks to data collection and analysis of energy consumption and occupancy patterns. Smart lighting for increased security can be tailored to meet traffic flow. Automated rapid access controls reduce building entrance time and security procedures are improved thanks to data collection and analysis.

Data collection and analysis through IoT also allows for quicker maintenance and upkeep. Smoke, carbon monoxide, and fire detection sensors can alert authorities and first responders immediately. Heating and cooling systems can signal malfunctions in real time so that repairs can be addressed promptly.

Improved Connectivity

Students require better, faster, and more reliable Wi-Fi connections along with cellular signals. Apart from completing coursework, greater reliability in connectivity also permits students to remain in contact with friends and family members, alleviating parent worries. 

Campus dorms are now boosting connectivity with better networks and routers. Students benefit from stronger signals for personal needs but so do security processes and personnel. Better connectivity permits those responsible for security and safety to benefit from monitoring without interruption and to use remote security solutions such as lockdowns should the need arise.

Alarm Systems

While alarm systems are regularly used for smoke, fire, and carbon monoxide detection, student security does not end with these three threats. Alarm systems can notify students and administrators of unauthorized accesses or break-ins, intrusions, broken glass, gunshots, and dangers in general.

Cloud-based alarm systems send out mobile alerts in real-time and offer the possibility to program automatic lockdowns or evacuations when called for. Internal and external locks can be managed to contain specific threats to a limited area within the dormitory.

All Things Considered 

Security technology now aids administrators and college security personnel in providing a safer environment for university students. Parents can feel better about their children being away at college. Thanks to technological advancements being adopted within university housing, students enjoy a better-quality residential experience. Safety and security are increased allowing students to enjoy their university experience while focusing on their studies.

Featured image by Adrien Olichon on Unsplash

The post How On-Campus Housing Security Is Transforming Thanks to Technology appeared first on noupe.

Categories: Others Tags:

How To Deal With Big Tooling Upgrades In Large Organizations

May 17th, 2023 No comments

If you work in software development, you probably know a thing or two about using and maintaining third-party packages. While third-party tooling has its fair share of downsides, there are plenty of advantages as well. The efficiency you get from code that someone else has already written speeds up development and is hard to deny. Sure, there are all sorts of considerations to take in before plopping code from a third party — accessibility, technical debt, and security, to name a few — but the benefits may make taking on those considerations worthwhile for your team.

Upgrades are also part of that set of considerations. Usually, your team may treat this sort of maintenance as a simple task or chore: upgrading dependencies and (automatically) validating that all of the features keep functioning as expected. You probably even have automated checks for keeping all package versions up to date.

But what if the third-party tooling you adopt is big? I mean big, big. That’s common in large organizations. I happen to work for a fairly large organization that leverages big third-party resources, and upgrading those tools is never as simple as running a package update and moving on. I thought I’d share what’s involved in that process because there are many moving pieces that require ample planning, strategy, and coordination. Our team has learned a lot about the process that I hope will benefit you and your team as well.

Some Context On My Organization

I work for Jumbo Supermarkten in the Jumbo Tech Campus (JTC), which is a department of over 350 developers working in agile teams on a range of digital products that help facilitate our core grocery and e-commerce processes.

We have a variety of responsibilities, where 70% of the work is allocated to the primary objectives for each team, and the remaining 30% is dedicated to anything a team wants, as long as it is beneficial to the JTC, which is very useful if you want to deliver value outside of your own team.

When we look at maintaining tooling and packages, balancing the goals of each team with the goals of JTC means that teams effectively maintain their own codebases while also collectively maintaining internally shared codebases that serve as the tooling and foundation of our applications.

Centralized Code As A Bottleneck

To build our applications with consistent standards, we rely on an internal design system and the component library we call Kompas (Dutch for “Compass”). We have built this system ourselves and rely on Vue to render our components and build interactions. Kompas is a hard dependency for virtually all of our applications to ensure uniformity.

This project was not allocated to a dedicated team. Instead, we adopted a strategy that introduced plenty of guidance to allow all front-end developers to contribute. Any developer can add new components to the library as well as features to existing components and keep everything in sync with the designs.

Teams normally work on business features since product owners love delivering customer value. The way we set up our process would allow a team to, in one sprint:

  • Make the required change in Kompas,
  • Have it reviewed by peers from both inside and outside a particular team,
  • Publish the latest version of the component library, and
  • Use that version in that team’s own application to deliver to the end user.

We can only do this with automation on repetitive processes — linting, formatting, quality assurance, testing, visual comparisons, and publishing — in order to provide enough room for developers to contribute to the process. Our component library is very much a living document of our design system, with multiple minor releases and patches a week. With semantic versioning, we can keep our own applications up to date easily and with confidence.

For bigger undertakings, such as setting up visual snapshot tests, we established temporary working groups alongside our existing teams that we called “front-end chapters” where members join on a voluntary basis. In these meetings, we discuss what needs to be done, and in the available 30% of free time we are allotted, the members of these teams carry out the work and report back to the chapter.

As you can imagine, we’ve spent a lot of time and effort ensuring the quality and making it a reliable part of our landscape.

This all began when Vue was in Version 2. That’s the version we baked into Kompas, which means we effectively forced our whole application landscape to follow suit. This worked perfectly for us; people could focus on their team’s needs while leaning on the support of the entire front-end chapter that works on Kompas.

Following the Vue ecosystem that we introduced, Vuex and Nuxt became part of our environment. And then Vue 3 was announced, and it was a massive breaking change from Vue 2! With the announcement, the end-of-life date for Vue 2 was set for December 31, 2023. We still have some time as of this writing, but the news had a massive impact that cascaded throughout our organization.

We Needed A Strategy

We needed to upgrade Vue from 2 to 3. The first thing that we needed to figure out was when we could reasonably start the process. To assess and strategize, we formed a small virtual team of developers consisting of members from various teams so that multiple perspectives were represented.

We figured that there would be a period of time when we would need to support both versions in order to allow time for migrating between teams. It would be nearly impossible to orchestrate a monolithic release. Thus, we prefer gradual incrementing over massive sweeping changes. On the other hand, having to maintain two versions of Vue for, basically, the same business feature presented costs in time and complexity.

So, in order to execute this process as responsibly as possible, we set out to figure out when we could start, taking into account the longevity of maintaining two codebases while getting early experience from upgrading. We started to map the different tech stacks for each team and plotted out potential bottlenecks for the sake of making the process of our work as widely visible as possible. At this time, our organization had a very flat structure, so we also needed to get internal stakeholders (i.e., product owners, architects, and managers) involved and convey the effect this upgrade would have on teams across the board.

Creating A Map

With our starting point set, we move on to establish a direction. Not having a dedicated team did pose some challenges because it meant that we needed to align everybody in a democratic way. This is, in Dutch culture, also known as polderen:

We try to find consensus in a way where everybody is equally happy, or unhappy, about the final direction.

And this can be challenging in a department that consists of many cultures!

One thing we knew we could rely on was the published best practices from official Vue resources to guide our decision-making process. Referencing the documentation, we did notice opportunities for incremental upgrades. The release of Vue 2.7 (Naruto) was really helpful in the sense that it backported features from Vue 3 back to a Vue 2-compatible version.

We also noted that in our landscape, not all applications were actually using Nuxt. A stable release of Nuxt 3 would be a prerequisite for those applications to even be considered for migration since the Vue major version is tightly coupled with the Nuxt major version. Luckily, some applications in our landscape are standalone Vue apps. These are ideal candidates for the first Vue 3-compatible components.

But first, we would need to have components that were compatible with Vue 3.

The Big Divide

By this point, we were confident enough to get to work. We had a plan and clear strategy, after all. The first order of business was to make sure that our component library was compatible with Vue 3, preferably while minimizing duplicative efforts.

We found a really nice way of doing this:

We created a new workspace called “Kompas-next” next to the regular components folder, which was scaffolded out using Vue 3. Then we imported the components from the original library.

This only works because:

  • The backported features in Vue 2.7 allowed us to move closer toward the Vue 3 composition API (among other things).
  • The component syntax between Vue 2 and Vue 3 isn’t radically different anymore.
  • Vue Demi allowed us to convert components, one by one, to be compatible with both versions.
  • We made sure that Kompas-next runs isolated tests to ensure stability.

We did have to slightly modify each and every component to adapt to the new standards. We’ll get to that process in a minute.

That said, we were able to publish two versions of our component library: one that is compatible with Vue 2 (Kompas) and one that is compatible with Vue 3 (Kompas-next). This, in turn, meant that the teams that did not have Nuxt as a dependency could potentially start migrating!

Getting Organized

Up to this point, most of the groundwork had been done in a relatively small team. We were in charge of the investigations, communication, and alignment. But we still needed to get stuff done — a lot of stuff!

With every developer being able to contribute, we came to an agreement that fits with the way everybody was already contributing to the component library:

If you touch a component that is not yet compatible, convert it to be compliant with both Vue 2 and Vue 3 using Vue-demi. Add the existing component with tests to the imports of the Kompas-next folder.

Having communicated this strategy early in the process, we immediately saw the Kompas-next library growing. The Vue core team has put so much effort into closing the gap between the two versions, which made our lives much easier.

Feedback From Early Adopters

The teams that were not blocked by a Nuxt 3 release could spend their time migrating their complete app to Vue 3, providing feedback along the way on how we were setting up our packages and converting components.

Seeing the first applications using Vue 3 was a milestone we could all be proud of since we managed to reach it together, collaboratively, and with a united strategy. The strategy worked for us because it closely resembled the way we were already working.

There were indeed some components that were not migrated using this strategy, which indicated to us that they were stale in terms of development. We reasoned that “stale” equals “stable” and that it would be perfectly fine to migrate them by manual assignment and distribution since we can expect it to be close to a one-off migration per component.

We also started to add Vue 3-specific capabilities to our component library, such as our own composables. I think that’s a nice testament to the investment and adoption by our front-end chapter.

With the component library now supporting Vue, we cleared a significant migration hurdle in our organization. We enabled teams to start migrating to Vue 3, and we encouraged new applications to use the latest standards. As a result, we could start thinking about a deprecation path for our Vue 2 codebase. We were cautiously optimistic and aligned the end-of-life date for Kompas with the same date for Vue 2: December 31, 2023.

So, yes, we are not yet finished and still have work to do. In fact, we had…

Two (Minor) Elephants In The Room

To support communication between micro-applications that run on our e-commerce domain, we had resorted to using Vuex in the past. We used to register stores globally so other applications could dispatch actions and retrieve a shared state. This is now gradually being migrated in the sense that we are replacing Vuex with Pinia for internal state management.

For cross-app communication, we are in the process of decoupling Vuex as an external interface and promoting the use of custom events tied to a specific domain. This prevents us from locking ourselves out of future state management tooling.

We are also in the process of preparing our Nuxt applications to be cleared for migration as well. Within our e-commerce domain, we’ve been building specific modules that take a lot of overhead out of our hands: They handle tasks like setting meta headers, security, and analytics. These are being rewritten to use plugins rather than modules. The impact of this breaking change is smaller because it is limited to the teams that use these modules. We see that these teams are using a similar strategy, albeit on a smaller scale, to organize and structure the tasks at hand.

Looking Back

I believe we have a few key takeaways from how we upgraded (and continue to upgrade) from one version of a large third-party resource to another within our large network of teams and shared codebases. I believe the lessons we learned are relevant beyond Vue and can be applied to the processes of other large organizations migrating between versions of a core piece of architecture.

Let’s review what we learned:

  • Ensure the transition period is clear and as short as possible.
  • Facilitate breaking the work down into small steps that progress iteratively and solicit feedback from those involved in the process as early and as often as possible.
  • Onboard key stakeholders to make sure your team has ample time and resources to do the work.
  • Define a strategy that fits with your organization’s culture.
  • Foster a collaborative mindset and establish clear communication between teams.
  • Celebrate wins, even the smallest ones!

The Work Is Never Done, Really

As I mentioned earlier, maintenance is a never-ending piece of the software development process. As Vue creator Evan You stated in the State of the Vuenion 2023, Vue plans to ship more frequent updates and releases. This will keep impacting our work, but that’s okay. We have a plan and blueprint for future releases.

We’re not there yet, but we now know how to get there!

Further Reading On SmashingMag

Categories: Others Tags:

4 Common Recruitment Challenges and How to Overcome Them

May 17th, 2023 No comments

Corporate leaders and hiring managers are being pressed to exhibit tremendous patience, creativity, and determination right now. As of May 2023, the U.S. labor market is experiencing a serious glut of job seekers. According to government statistics, there are more than four million positions than there are available workers. In other words, it’s still very difficult to get people to even apply for advertisements, let alone fill seats.

There are countless reasons for the labor shortage. The Great Resignation (or Migration, as some call it), has certainly affected recruitment efforts. When people know they’re needed, they’re less likely to accept the first job they’re offered. And though mass resignations are expected to drop by the end of 2023, they’re still happening. Another factor has been a change in the way professionals want to work. When Slack conducted a survey on virtual work arrangements, 94% of respondents said they wanted remote options. That’s a hard sell for some companies and in specific careers like healthcare and manufacturing.

Of course, this doesn’t mean you’re without choices if you have openings to fill. You just need to acknowledge your biggest recruitment challenges and then find ways to bypass them. To help you start, consider the following hiring conundrums and how to overcome them.

Challenge #1: You can’t find qualified applicants.

You post on all the same job boards that have worked like a charm before. But your results? Well, they’re not exactly what you want. You keep getting hits from candidates who don’t even have the basic skills or experience you need. That’s a problem, because you can’t wait forever to build out your dream team and start to scale.

The first strategy to take if you’re in this boat is to consider hiring people overseas. As long as the work can be done anywhere by the right person, you’re good to go global. The only potential snag is that you’ll want to plan ahead. Bringing aboard employees from other countries requires a knowledgeable partner’s legal and financial savvy. For example, Oyster offers automated global hiring management assistance for its customers. Join forces with a global employment platform like Oyster and you won’t have to worry about being compliant with foreign regulations and rules. You’ll just get to expand your talent pool while mitigating your risks. 

The second strategy is to try novel recruitment methods. You might want to search for potentially qualified people on LinkedIn and send them a “cold call” note. Or, you could try smaller, niche job sites like those aimed at minority worker groups. Even if you get just a few more hits than usual, you’ll be ahead of where you would have been.

Challenge #2: You lose tons of candidates throughout the interview process.

It’s happened again: You’ve found some amazing applicants who’ve submitted their resumes. As your hiring team looks over all the candidates’ information, you get pretty excited. Why wouldn’t you, when you have so many possibilities? Yet by the time you reach the one-on-one interview stage, most of those candidates have gone elsewhere. The result? You have to start the process over again — and you’ve lost lots of time.

If this challenge sounds far too familiar, you probably have to take a look at your hiring journey. Many corporations have made it very time-consuming to move applicants through the hiring process. They’re not trying to be difficult, of course. They want to make sure they don’t end up with a bad fit. Nevertheless, their hesitation winds up hurting them in the long run because candidates don’t want to wait. According to Indeed, the average after-interview response time from company to interviewee is 24 days. Even if you’re in that sweet spot, consider moving more quickly.

With so many jobs available, high performers will take the best offer they get. Even if you can only shave a few days or a week off your hiring, you could see instant improvement. Be sure not to scale back too much, but do consider where you can tighten everything.

Challenge #3: Applicants don’t have the skill sets you want.

You’ve been advertising some positions for weeks. You’re getting resumes, which is good. However, you’re not getting anyone with all the skill sets you want. Although you’ve made requirements clear in your advertisement, you’re not seeing those requirements reflected in applications. What gives?

The answer may not be one you want to hear, but it’s one you need to consider: Your bar may be too high. In other words, you’re trying to get a unicorn employee. Do unicorn employees exist? Perhaps in some universe, but your chances of seeing one may be lower than you presumed. Consequently, you’re better off looking for someone who can be trained on the skill sets you want.

Think of this as a switch to hiring based on a talent’s potential. You’re seeking someone not with all the qualifications intact but with the characteristics to learn. It’s not a matter of lowering your standards, though. You’ll need to set up a training plan for the person you hire. That’s okay and may actually make you a more appealing prospective employer. More than six out of 10 workers would trade their loyalty for the opportunity to upskill on their company’s dime.

Challenge #4: Diverse candidates just don’t seem to be interested in working at your company.

Diversity, equity, and inclusion (DEI) have become an important part of the mission of many companies. Yet it’s hard to foster support for DEI initiatives if you’re not hiring people from historically underrepresented populations. If you’ve seen no uptick in the diversity of your candidates, you may need to make some changes.

Initially, look at your job description. Are you using biased language unintentionally? Your advertisements and postings could sound perfectly reasonable to you but be a “turnoff” to diverse candidates. Even using terms like “rockstar” or adding gendered language to your job postings could be having an adverse effect. Now may be the perfect time to review everything you’re posting to spot any unintentionally biased or coded phrasings.

Next, revamp your worker sourcing. Look for untapped candidate pools that focus on Black candidates, Latinx candidates, veterans, LGBTQ+ applicants, and job seekers from other diverse communities. You may even want to consider advertising on specific diverse platforms or to social media groups. Done well, this can boost your application numbers representing more diverse talent backgrounds and abilities.

Recruiting isn’t the easiest task in the world, that’s certain. However, it’s possible to refine your processes so you can fill positions more dependably and with great people.

Image by yanalya on Freepik

The post 4 Common Recruitment Challenges and How to Overcome Them appeared first on noupe.

Categories: Others Tags: