with Special Guest Igor Aronov
Q&A
- Amy Chan
- Svetlana Gulotta
- Nicholas Santillan
- Richard McQuillin
- Michael Hanttula
- Eagle wpHelpDesk
Amy Chan Q: How would pixel perfect design work with screen size changes? What do you you communicate with dev for those changes?
Igor answered @ screen size changes with creating explicit designs for major breakpoints / sizes and the benefit of his designers and developers collaborating together for years which solidifies known expectations and fosters shared understanding.
Communicating these needs across design, dev, and even clients is another benefit of having a standard approach and expectations that have been documented, shared, discussed and practiced.
Cheryl Xu spoke at our March Meetup and covered a lot of this ground: Having a Style Guide, standard tools and practices, and lots of ongoing discussions with clients and project teams. Cheryl’s presentation and discussions around it surfaced at least 4 or 5 topics we should revisit each as its own session. I think you’ll find both helpful:
“How do you justify your design?” with Special Guest Cheryl Xu
Svetlana Gulotta Do you keep in mind the WordPress capabilities when designing the Figma mockups for clients?
Igor answered with the holistic approach his designers and devs take together en route to Pixel-Perfection. Neither work stream happens in a silo – Figma designs are discussed along with the end-goals for look/feel/function. Devs share their approach to meet goals. Designers get more familiar with WP capes and Devs learn to raise flags when designs being requested are far-afield from WP’s core capabilities.
This fits well with Nick’s question about “how high in fidelity do you go in your wireframes?” With Design and Development collaborating from the outset, the work-in-progress in WordPress is a living wireframe on the path to project completion. This Living Wireframe is one of the strongest cases for building atop WP.
Nicholas Santillan also asked about maintaining designs once they’ve been handed off to clients.
Michael Hanttula was super-helpful as always sharing links and answering questions. More tk there –
Eagle wpHelpDesk answered Richard and others. Thank you, and Welcome to [WPLA]!
Richard McQuillin
- Is looking for WP devs in South Bay (LA) and shared his contact info – [email protected]
- Asked about privacy and Intellectual Property considerations when using SaaS and cloud services. There are many. When doing work for others, strive to comply even when clients are not.
- Asked about page builders (Elementor et al). Igor answered that his team avoids them. Others concurred citing code and style bloat, lack of standards across WP sites and implementations, and conflicts with other plugins and themes. Stick with Blocks and core as possible. The same holds true for plugins.
- Asked about WP and complex requirements: When to use WP and when to approach it as a full custom application.
Michael Hanttula‘s correct answer was
“It really depends on your site’s needs & the nature of the content you’re seeking to present. Plus considerations like timelines, budget, etc.”
@Richard Q: You mentioned “a sorta complex scheduling application” as prompting this question. Share more about that here so I and others can respond and we can all learn.
Rules of thumb I use here:
I. If the folks creating content on an ongoing basis are 1) few, 2) more comfortable with page builders than with 3) content tools you’re comfortable delivering, use the page builder.
II. Learn from page builders to 1. improve content / site management tools you create and 2. streamline them through configuration when possible (same with plugins)
My initial thoughts: If it’s ‘Scheduling’ like Meetings, Participants, Conference Rooms and Availabilities or the like, Outlook / O260 or Google Workspace do that well.
If it’s ‘Scheduling’ like running server jobs at defined times to collect, process, distribute data, cron, git, Puppet and Chef do that well.
WordPress does great work consuming data from all of those things so your site or app can use, act-on, and display what’s appropriate to the people looking.
Richard’s question recurs often in client and corporate conditions. Heuristics I use include these.
I. Build atop WordPress:
- When the plan calls for ongoing content creation, use WordPress.
- When there are people, groups and roles who need to review/update/approve/publish content, use WordPress.
- When you’re working with digital assets (video, photos, documents) sourced from or accessed by more than one person, use WordPress.
- When your site or app will have login with visitors and users seeing different content / features / functionality when logged in, use WordPress.
II. Start elsewhere when your goal is focused on
- Clickstream and telemetry data processing
- Analytics and OLAP processing
- Handling transactional loads that reach into the tens of thousands events or records per hour
III. When you have functionality required that’s like II, but also includes some of I, build it alongside WordPress in .NET, golang, js and integrate it.
Loose integrations through links and REST calls are quick – days not weeks. We can tighten these integrations with plugins and themes you create or discover. We deepen them further with abundant SDKs, APIs and prior art from a gigantic community.