Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
A new year is upon us and that means many people take a moment to pause and reflect on the goals they wish to achieve for themselves over the course of the next 12 months. Setting resolutions looks different for …
9 Great Call To Action Plugins For WordPress Read More »
I come across this problem every so often and end up having to do work arounds when I would prefer to keep it in the database. I have a query where the data in the query updates frequently so the query won't stay in the cache but I don't need the query to be accurate. I was trying to avoid adding an extra step of storing the data in a temp table and having to update it on a timer.
Does anyone know of a way to get MariaDB or MySQL to Keep the result set for a period of an hour or so before actually running the query again, I have an example of a query below which takes between 4.8-6 seconds to run and the wait is too long and also is needless work for the server, It can just do the query once and get the 4 numbers - then all subsequent requests just return the 4 numbers and every 20 minutes or 1 hour the 4 numbers get updated.
Is there a built in funtion for this or is the only solution to make your own table? I could end up with many of these and I don't want to end up with 100's
SELECT
SUM(CASE WHEN p.id IS NULL AND f.loc = 1 THEN 1 ELSE 0 END)/250 to_print
, SUM(CASE WHEN p.id IS NULL AND f.loc NOT IN(1,2,8) THEN 1 ELSE 0 END)/250 to_print_out
, SUM(CASE WHEN p.id IS NOT NULL AND p.print_date BETWEEN '2020-01-09 14:00:00' AND '2020-01-16 14:00:00' THEN 1 ELSE 0 END)/250 printed_tw
, SUM(CASE WHEN p.id IS NOT NULL THEN 1 ELSE 0 END)/250 printed
FROM typist t
LEFT JOIN printing p ON t.typed_id = p.print_id AND p.type = 4
LEFT JOIN files f ON t.file_id = f.file_id
WHERE
t.type = 1
AND f.file_id IS NOT NULL
AND NOT EXISTS(SELECT DISTINCT l.id FROM letters l WHERE l.deleted = 1 AND t.letter_id = l.id)This is the EXPLAIN for the query
"1" "PRIMARY" "t" "ref" "file_id,letter_type,print_stat" "print_stat" "2" "const" "134243" "Using where; Using index"
"1" "PRIMARY" "f" "eq_ref" "PRIMARY" "PRIMARY" "3" "sys.t.file_id" "1" ""
"1" "PRIMARY" "p" "ref" "id,type" "particle_id" "8" "sys.t.typed_id" "1" "Using where"
"2" "MATERIALIZED" "l" "ref" "PRIMARY,deleted,deleted_file_id" "deleted" "1" "const" "4741" "Using index"I have already had numerous variations to try optimising this and the above is the best I have got so far. t has around 200,000 rows, l has around 300,000, f has about 130,000, p has around 300,000 but will bloat well over 1,000,000 in time.
The text logo has a slash cut through the text. You set two copies on top of one another, cropping both of them with the clip-path property.
What's interesting to me is how many cool design effects require multiple copies of an element to do something cool. To get the extra copy, at least with text, we can sometimes use a pseudo-element. For more elaborate content, there is an element() function in CSS, but it's limited to a prefixed property in Firefox. Still, it enables awesome stuff, like making a mini-map of long content.
You can style it differently with a pseudo-element, which was useful here. Might be cool to see a way to clone elements on a page and apply styling all through CSS... someday.
See the Pen
His Dark Materials TV series logo with CSS by Michelle Barker (@michellebarker)
on CodePen.
Direct Link to Article — Permalink
The post Re-creating the ‘His Dark Materials’ Logo in CSS appeared first on CSS-Tricks.
It's notable that Water.css was the #1 clicked thing from Louis Lazaris' Web Tools Weekly in 2019. It's from a 13-year old developer named Felix!
It's just a little bit of CSS you apply to class-free semantic HTML to give it nice basic responsive styles — the perfect kind of thing for a Pen when you are just tossing some markup together and want it to look nice.
Direct Link to Article — Permalink
The post Water.css appeared first on CSS-Tricks.
The Open Geospatial Consortium (OGC) has announced the formation of a Standards Working Group (SWG) that will aim to establish API standards to assist in the distribution of environmental data.
what3words, an innovative location solution provider, just announced its new Voice API, powered by Speechmatics. what3words has divided the world into three-meter squares, with each square represented by a unique set of three individual words (e.g. the three word identifier for the what3words headquarters is filled-count-soap). By using a three-word identifier, duplicative and mispronounced street addresses are eliminated.
The start of a new year is a great time for freelance web designers to launch a business review. It’s an opportunity to take a look at where you’ve been, where you are and where you want to go.
So …
The answer used to be absolutely yes because, if you used px units, you prevented the text from being resized by the user at all.
But browser zoom is the default method for making everything bigger (including text) these days and it works great even if you use px.
But... Kathleen McMahon really digs into this and finds that it's still worth setting all your type (both font-size and line-height) in relative units because:
px prevents browser settings from making font size adjustments (which some people definitely use) andDirect Link to Article — Permalink
The post Is it better to use ems/rems than px for font-size? appeared first on CSS-Tricks.
Here’s a story you’ll love if you want to speed up your WordPress site. The other day I built a shiny website. I went all out and added WooCommerce, Google Tag Manager, OneSignal, helpdesk, Yoast, live radio (oh yes I did), Cookie Notice, social media, and a bunch of other plugins. Just like you, I […]
The post How to Reduce HTTP/S Requests in WordPress appeared first on WPExplorer.
The content management systems (CMS) like WordPress have made the creation and management of websites and blogs very easier. WordPress, Drupal, and Joomla are currently the top content management systems out there. These systems provide some tools to help you build websites. These tools are different for every platform, having their pros and cons. But […]
The post How secure is WordPress as compared to other CMS? appeared first on designrfix.com.
These days starting your own online store doesn’t have to be just a dream. Thanks to WordPress anyone can build an online store with WooCommerce. It’s quick, fairly easy and you can set up a professional looking website to sell your products without spending a ton of money. What’s more, with these simple WooCommerce tips […]
The post Simple WooCommerce Tips to Make Your Store Even Better appeared first on WPExplorer.
God I'm funny.
Anytime we have fairly repetitive selectors that have a common parent, it's probably a place we can use the :is() pseudo-selector.
Holger Bartel demonstrates like this:
section section h1, section article h1, section aside h1, section nav h1,
article section h1, article article h1, article aside h1, article nav h1,
aside section h1, aside article h1, aside aside h1, aside nav h1,
nav section h1, nav article h1, nav aside h1, nav nav h1 {
font-size: 20px;
}Becomes:
:is(section, article, aside, nav)
:is(section, article, aside, nav) h1 {
font-size: 20px;
}
Adam Argyle demonstrated like this:
:is() selector 🎉
the successor to :any() and :matches()sneak peak into our talk, here's a neat gif I made with XD showing what the :is() selector syntax can do. be excited for Chrome Dev Summit y'all!https://t.co/0r2CcUx9Hv pic.twitter.com/wSuGOsDLvZ
— Adam Argyle (@argyleink) November 7, 2019
MDN has an extra dramatic one:
ol ol ul, ol ul ul, ol menu ul, ol dir ul,
ol ol menu, ol ul menu, ol menu menu, ol dir menu,
ol ol dir, ol ul dir, ol menu dir, ol dir dir,
ul ol ul, ul ul ul, ul menu ul, ul dir ul,
ul ol menu, ul ul menu, ul menu menu, ul dir menu,
ul ol dir, ul ul dir, ul menu dir, ul dir dir,
menu ol ul, menu ul ul, menu menu ul, menu dir ul,
menu ol menu, menu ul menu, menu menu menu, menu dir menu,
menu ol dir, menu ul dir, menu menu dir, menu dir dir,
dir ol ul, dir ul ul, dir menu ul, dir dir ul,
dir ol menu, dir ul menu, dir menu menu, dir dir menu,
dir ol dir, dir ul dir, dir menu dir, dir dir dir {
list-style-type: square;
}:is(ol, ul, menu, dir) :is(ol, ul, menu, dir) ul,
:is(ol, ul, menu, dir) :is(ol, ul, menu, dir) menu,
:is(ol, ul, menu, dir) :is(ol, ul, menu, dir) dir {
list-style-type: square;
}It's less code and easier to reason.
Kezz Bracey notes that pairing it with :not() can be nice as well:
:not(article, section, aside) :is(h1, h2, h3, h4, h5, h6) {
font-weight: 400;
}Browser support is just starting to get there and polyfilling is hard, so we aren't at day-to-day no-brainer use levels quite yet. I'd bet it's not too far away.
The post Is “is” Useful? appeared first on CSS-Tricks.
Drew McLellan puts the chairs up on the tables, sweeps the floor, and closes off our season, and indeed the entire 24 ways project with a look back at what it’s meant to run this site as a site project, and what impact side projects can have on the work we do. Will the last one out turn off Christmas the lights?
Fifteen years ago, on a bit of a whim, I decided it would be fun to have a Web Standards version of something like the Perl Advent calendar. A simple website with a new tip or trick each day leading the readers through December up until Christmas.
I emailed a bunch of friends that kept web design and development themed blogs (remember those?) suggesting the idea and asking if they’d like to contribute. My vision had been that each post would be a couple of paragraphs of information. A small nugget of an idea, or a tip, or a suggestion. What happened was something really amazing. I began to receive really insightful blog posts containing some of the most valuable writing I’d seen online all year.
Look at this piece from Ethan Marcotte on Centered Tabs with CSS, or this detailed piece on scripting block quotes from Jeremy Keith. I was blown away, and the scene was set.
What I hadn’t anticipated in 2005 was that this little side project would turn into a fixture of the industry calendar, would introduce me to a raft of field experts, and would have me working with an eclectic team of collaborators for fifteen long seasons.
And that last point is crucial. I’ve by no means produced this alone. Rachel Andrew has been a constant supporter in helping each year to see the light of day and producing our ebooks. After a couple of years, Brian Suda stepped in to help me plan and select authors. In 2008, I managed to persuade Tim Van Damme to replace my very basic site design with something altogether more fitting. In 2010, Anna Debenham came on board initially to help with the production of articles, but rapidly became a co-producer working with me on all aspects of the content. Owen Gregory joined up that same year to help with the proofing and editing of articles, and for many years did a fantastic job writing the home page article teasers, which are now but a shadow of their former selves.
Also in 2010, we produced a book in collaboration with Five Simple Steps and raising funds in the memory of Remy and Julie’s daughter, Tia Sharp.
In 2013, Paul Robert Lloyd stepped up to the plate to provide us with the design you see today, which not only subtly shifts colours between each day, but across the years as well. Compare the reds of 2005 to the purples of 2019, and the warm tones of a Day 1 to its correspondingly cool Day 24. It’s a terrific piece of work.
In 2014 we won a Net Award for Best Collaborative Project at a fancy ceremony in London. Many past authors were there, and as it was an aware for our collaborative efforts, we all posed with the glassware for photos.
But even I, Sea Captain Belly Button am not enough of a navel gazer to just be writing an article just about this website. As we draw our fifteenth and final year to a close, it’s important to reflect on what can be learned. Not from the articles (so much!) or from the folly of committing to a nightly publishing schedule for a month every year for fifteen years (don’t do it!) but from the value in starting something not because you have to, but just because you want to. From scratching an itch. From working with a friend just because you love spending time with them. Or for doing something because you see the opportunity for good.
As web designers and developers, we have the opportunity to turn the skills we use in our profession to so many different purposes. In doing so you never know what good might come from it.
This week I asked around to find out what good others have seen from their side projects. Long time 24 ways contributor Simon Willison had this to say:
Basically every job I’ve ever had relates back to a side-project in some way
— Simon Willison (@simonw) December 17, 2019
Simon went onto explain how it was a website side project that got him his first job in tech. After that, his personal blog lead him to getting a job at Lawrence Journal-World where he created Django. On his honeymoon, Simon and his new wife (and 24 ways contributor) Natalie Downe created Lanyrd, and Simon’s more recent Datasette project landed him a JSK Fellowship at Stanford. That’s an impressive record of side projects, for sure.
Others had similar stories. My good friend Meri Williams is currently CTO of challenger bank Monzo, as well as being a trustee at Stonewall and Chair of The Lead Developer conference.
I got asked to write the book you tech reviewed off the back of a Meetup talk.
Chairing @TheLeadDev has led to me getting to hire & work with so many new brilliant people, as well as getting me multiple CTO gigs (both perm & interim)Got the gig chairing Lead Dev after meeting @RuthYarnit at a dev meet-up in the basement of a pub in Reading (which I think @drewm you also spoke at / introduced me to!)
— Meri Williams 🌈💪🏾 (@Geek_Manager) December 18, 2019
Leading LGBTQ employee network at P&G eventually led to my applying for board role at Stonewall
Again, an impressive list of achievements, and I’m sure both Simon and Meri would have eventally found other routes to their individual success, but the reality is they did it through side projects. Through being present and active, contributing a little to their communities, and receiving so much more back in return.
Of course, not all projects have to be directly related to the web or software to be fulfilling. Of course they don’t. Mark Small and Jack Shoulder embraced their love of a good rear end and created MuseumBums, informally cataloging perfect posteriors for your perusing pleasure. On its success, Mark says:
Ok! We’ve been profiled in the Cambridge Independent, the Sun and the Metro; raised money for Prostate Cancer UK; created a little community of museum fans who aren’t afraid to be a bit silly online; and we’ve got a list of big ideas for developing our 👍🏛️🍑 offer further! 😁
— Marky Smallstice 🎄👓🌈 (@thehistoryb0y) December 17, 2019
Jack adds:
We’ve also got a shout out on @BBCRadio4 and helped a beloved museum achieve record numbers of visitors.
— Jack Frost (@jackshoulder) December 17, 2019
Wow. It’s been a *year*
I had so many heartwarming responses to my request for stories, I really recommend you go over to the thread on Twitter and read it. It’s been one of my favourite set of replies in a long time.
As the years progressed, more and more publications sprang up both at Christmas and throughout the year with how-to articles explaining techniques. As a natural response, 24 ways started mixing up solution-based articles with bigger picture takes on a wider range of topics, but always with a practical takeaway to impress your friends.
After the embarrassment of white dudes that dominated the early years, we actively sought to open the opportunity to write to a wider and more diverse range of experts. While I don’t think we ever got as much racial diversity in our lineup as I would have liked to have achieved, I’m very proud that each season has been closely gender-balanced since 2012. This is something that was never forced or remotely hard to achieve, all it took was an awareness of the potential for bias.
With all the benefits that side projects can bring, it’s also important to be mindful of downsides. Not every project will take flight, and those that do can also start to consume valuable time. That’s fine while it’s fun and you’re seeing the benefits, but it’s neither fun or healthy long-term to have no time away from something that might otherwise be your job.
Spending time with family, friends, and loved ones is equally important especially at this time of year. Just as anyone who does a lot of sport or fitness will tell you about the value of rest days between your activities to let the body recover, time away from ‘work’ is important to do the same for your brain.
Having run this site every Christmas for 15 seasons, it’s time to take a breather and give it a rest. Who knows if we might return in the future, but no promises. It’s been a good run, and an absolute privilege to provide this small tradition to the community I love.
So from me and the whole 24 ways family, Happy Christmas to all, and to all a good night.
Drew McLellan is a developer and content management consultant from Bristol, England. He’s the lead developer for the popular Perch and Perch Runway content management systems, and public speaking portfolio site Notist. Drew was formerly Group Lead at the Web Standards Project, and a Search Innovation engineer at Yahoo!. When not publishing 24 ways, he keeps a personal site about web development, takes photos, tweets a lot and tries to stay upright on his bicycle.
Amy Hupe prepares a four bird roast of tasty treats so we can learn how the needs of many different types of users can be served through careful implementation of components within a design system.
Design systems help us to make our products consistent, and to make sure we’re creating them in the most efficient way possible. They also help us to ensure our products are designed and built to a high quality; that they’re not only consistent in appearance, and efficiently-built, but that they are good. And good design means accessible design.
1 in 5 people in the UK have a long term illness, impairment or disability – and many more have a temporary disability. Designing accessible services is incredibly important from an ethical, reputational and commercial standpoint. For EU government websites and apps, accessibility is also a legal requirement.
With that in mind, I’ll explain the four main ways I think we can use design systems to promote accessible design within an organisation, and what design systems can’t do.
Design systems typically provide guidance and examples to aid the design process, showing what best practice looks like. Many design systems also encompass code that teams can use to take these elements into production. This gives us an opportunity to build good design into the foundations of our products, not just in terms of how they look, but also how they work. For everyone.
Let me give an example.
The GOV.UK Design System contains a component called the Summary list. It’s used in a few different contexts on GOV.UK, to summarise information. It’s often used at the end of a long or complex form, to let users check their answers before they send them, like this:
Users can review the information and, if they’ve entered something incorrectly, they can go back and edit their answer by clicking the “Change” link on the right-hand side. This works well if you can see the change link, because you can see which information it corresponds to.
In the top row, for example, I can see that the link is giving me the option to change the name I’ve entered because I can see the name label, and the name I put in is next to it.
However, if you’re using a screen reader, this link – and all the others – will just say “change”, and it becomes harder to tell what you’re selecting. So to help with this, the GOV.UK Design System team added some visually-hidden text to the code in the example, to make the link more descriptive.
Sighted users won’t see this text, but when a screen reader reads out the link, it’ll say “change name”. This makes the component more accessible, and helps it to satisfy a Web Content Accessibility Guidelines (WCAG 2.1) success criterion for links which says we must “provide link text that identifies the purpose of the link without needing additional context”.
By building our components with inclusion in mind, we can make it easier to make products accessible, before anyone’s even had to think about it. And that’s a great starting point. But that doesn’t mean we don’t have to think about it – we definitely do. And a design system can help with that too.
Having worked as the GOV.UK Design System’s content designer for the best part of 3 years, I’m somewhat biased about this, but I think that the most valuable aspect of a design system is its documentation.
(Here’s a shameless plug for my patterns Day talk on design system documentation earlier this year, if you want to know more about that.)
When it comes to accessibility, written documentation lets us guide good practice in a way that code and examples alone can’t.
By carefully documenting implementation rules for each component, we have an opportunity to distribute accessible design principles throughout a design system. This means design system users encounter them not just once, but repeatedly and frequently, in various contexts, which helps to build awareness over time.
For instance, WCAG 2.1 warns against using colour as “the only visual means of conveying information, calling an action, prompting a response or distinguishing a visual element”. This is a general principle to follow, but design system documentation lets us explain how this relates to specific components.
Take the GOV.UK Design System’s warning buttons. These are used for actions with serious, often destructive consequences that can’t easily be undone – like permanently deleting an account.
The example doesn’t tell you this, but the guidance explains that you shouldn’t rely on the red colour of warning buttons to communicate that the button performs a serious action, since not all users will be able to see the colour or understand what it signifies.
Instead, it says, “make sure the context and button text makes clear what will happen if the user selects it”. In this way, the colour is used as an enhancement for people who can interpret it, but it’s not necessary in order to understand it.
Making the code in our examples and component packages as accessible as possible by default is really important, but written documentation like this lets us be much more explicit about how to design accessible services.
In our design systems’ documentation, we’re telling people what good design looks like, so it’s really important that we practice what we preach.
Design systems are usually for members of staff, rather than members of the public. But if we want to build an inclusive workplace, we need to hold them to the same standards and ensure they’re accessible to everyone who might need to use them – today and in the future.
One of the ways we did this in my team, was by making sure the GOV.UK Design System supports users who need to customise the colours they use to browse the web. There are a range of different user needs for changing colours on the web. People who are sensitive to light, for instance, might find a white background too bright. And some users with dyslexia find certain colours easier to read than others.
My colleague, Nick Colley, wrote about the work we did to ensure GOV.UK Design System’s components will work when users change colours on GOV.UK. To ensure we weren’t introducing barriers to our colleagues, we also made it possible to customise colours in the GOV.UK Design System website itself.
Building this flexibility into our design system helps to support our colleagues who need it, but it also shows others that we’re committed to inclusion and removing barriers.
The examples I’ve drawn on here have mostly focused on design system documentation and tooling, but design systems are much bigger than that. In the fortuitously-timed “There is No Design System”, Jina reminds us that tooling is just one of the ways we systematise design:
…it’s a lot of people-focused work: Reviewing. Advising. Organizing. Coordinating. Triaging. Educating. Supporting.”
To make a design system successful, we can’t just build a set of components and hope they work. We have to actively help people find it, use it and contribute to it. That means we have to go out and talk about it. We have to support people in learning to use it and help new teams adopt it. These engagement activities and collaborative processes that sit around it can help to promote awareness of the why, not just the what.
At GDS, we ran workshops on accessibility in the design system, getting people to browse various web pages using visual impairment simulation glasses to understand how visually impaired users might experience our content. By working closely with our systems’ users and contributors like this, we have an opportunity to bring them along on the journey of making something accessible.
We can help them to test out their code and content and understand how they’ll work on different platforms, and how they might need to be adjusted to make sure they’re accessible. We can teach them what accessibility means in practice.
These kinds of activities are invaluable in helping to promote accessible design thinking. And these kinds of lessons – when taught well – are disseminated as colleagues share knowledge with their teams, departments and the wider industry.
Our industry’s excitement about design systems shows no signs of abating, and I’m excited about the opportunities it affords us to make accessible design the default, not an edge case. But I want to finish on a word about their limitations.
While a design system can help to promote awareness of the need to be accessible, and how to design products and services that are, a design system can’t make an organisation fundamentally care about accessibility.
Even with the help of a thoughtfully created design system, it’s still possible to make really inaccessible products if you’re not actively working to remove barriers. I feel lucky to have worked somewhere that prioritises accessibility. Thanks to the work of some really brilliant people, it’s just part of the fabric at GDS. (For more on that work and those brilliant people, I can’t think of a better place to start than my colleague Ollie Byford’s talk on inclusive forms.)
I’m far from being an accessibility expert, but I can write about this because I’ve worked in an organisation where it’s always a central consideration. This shouldn’t be something to feel lucky about. It should be the default, but sadly we’re not there yet. Not even close.
Earlier this year, Domino’s pizza was successfully sued by a blind customer after he was unable to order food on their website or mobile app, despite using screen-reading software. And in a recent study carried out by disability equality charity, Scope, 50% of respondents said that they had given up on buying a product because the website, app or in-store machine had accessibility issues.
Legally, reputationally and most importantly, morally, we all have a duty to do better. To make sure our products and services are accessible to everyone. We can use design systems to help us on that journey, but they’re just one part of our toolkit.
In the end, it’s about committing to the cause – doing the work to make things accessible. Because accessible design is good design.
Amy is a content specialist and design systems advocate who’s spent the last 3 years working as a Senior Content Designer at the Government Digital Service.
In that time, she’s led the content strategy for the GOV.UK Design System, including a straightforward and inclusive approach to documentation.
In January, Amy will continue her work in this space, in her new role as Product Manager for Babylon Health’s design system, DNA.