BONUS: Why a Former Chess Champion Thinks Your Leadership Is Stuck in the Opening Game

John Whitt spent 30 years managing billion-dollar construction portfolios in corporate America — sleeping five or six nights a week in hotel beds, traveling the country, winning at someone else's game. Then he walked away. In this episode, he breaks down what chess taught him about business phases, why generosity outperforms hustle in the long run, and how the "pause factor" keeps leaders from burning out while scaling their impact.

From Corporate Construction to Coaching — The Move That Changed Everything

"I spent 5, sometimes 6 nights a week, sleeping in a hotel bed, traveling around the country, and it really wasn't good for my sanity, it wasn't good for my family. And then the company decided to move from Southern California to Dallas, and so that was like the — I'm not going to Dallas move, and it's time to start something else."

John's corporate career was successful by every external measure — managing $500 million construction portfolios at companies like CB Richard Ellis. But the lifestyle was hollowing him out. He'd been thinking about leaving for a while when the relocation to Dallas forced his hand. Through behavioral assessment work, he discovered coaching was where his strengths naturally pointed — it had been his primary leadership style all along. In 2010, he invested in a Focal Point coaching franchise, which gave him the tools and training without having to reinvent the wheel. Combined with 30 years of corporate relationships, it was enough to launch. His reflection on the transition is simple: "The cool thing about coaching is that we're just helping people."

The Chess Game of Business — Opening, Middle, and End

"The way the chess game is played at the higher levels has influenced my way of thinking essentially for the rest of my life. The opening is where you're getting started — startup business, takes a lot of hustle, a lot of energy. But then the transition happens to the middle game, where you have to think a lot more strategically, and tactically with the right move in the right order, because the wrong order will not get you the results you're looking for."

John played in the United States Chess Championships in 1976, and the framework stuck. He maps business growth to three chess phases: the opening (startup hustle, high energy, you do everything), the middle game (strategic delegation, building systems, hiring people with an ownership mindset), and the end game (transitioning assets and resources to serve the life you actually want). The danger zone is the opening-to-middle transition. Founders and leaders get trapped being the go-to person for everything — solving everyone else's problems during business hours and doing their own work after hours and on weekends. The middle game demands a different skill: learning to operate on the business instead of always in it. And it can't happen overnight — you have to prioritize what to change, in what order, or it gets jumbled up.

Accomplishing Goals Through Others — The Magic of Discretionary Effort

"The magic is accomplishing goals through other people, because when you do that, you're going to do big things. As an individual, you can only do so much. There's only so many hours in a day."

John keeps coming back to one idea: if you're doing it all yourself, your impact is capped at 24 hours. The real unlock is getting other people to give their discretionary effort — that extra gear where someone stays 20 minutes longer because they care, or thinks about the project at home because they're genuinely excited. Discretionary effort isn't something you can demand. It comes from inspiration. John frames it through WIIFM — "What's In It For Me?" — everybody's favorite radio station. Leaders who skip that question get compliance. Leaders who answer it get mountains moved.

The flip side is equally important: many leaders have never been on a high-performing team, so they don't know what they're missing. They accept compliance as normal. Others are smart and capable but lack the relationship skills to inspire. John's point is clear: leadership through inspiration is a learnable skill, not an innate trait.

Generosity as Strategy — Time, Talent, and Treasure

"Generosity always — I mean, this is unequivocal — always gives you better long-term results. If you plan to be generous, if you say this is who I am and I will do the work that's necessary to be generous, then you will always get better long-term results."

John's 4-Facet LifeShine Generosity Process puts generosity at the center of leadership — an unusual move in a world that defaults to performance metrics and execution frameworks. His argument is that generosity isn't soft. It's strategic. The framework starts with unique identity (who are you?), then moves through three dimensions: time, talent, and treasure. Most people think generosity means writing a check. John says time and talent are far more powerful. A leader who invests the time to communicate vision and inspire the team is being generous — and that generosity compounds into better team performance, stronger relationships, and less burnout over time.

The risk, though, is over-giving. Agile coaches and scrum masters who tie their identity to the work are especially vulnerable — they give so generously at work that they burn out when results don't match expectations. That's where the plan matters: define the life you want, build the business or career to serve that life, and stay disciplined about boundaries.

The Pause Factor — How Leaders Protect Their Thinking

"You gotta learn to say pause. That's a great idea, I understand what you're saying, we need to spend a little more time on that — so let me schedule some time later. Because right now, if I spend all that time, it's not going to get my best thinking, it's not going to get my best response."

People bring problems to leaders constantly — personal problems, business problems, urgent and not-urgent mixed together. The instinct is to solve immediately. John teaches leaders the "pause factor": acknowledge the importance of what someone brings you, then schedule dedicated time to address it properly. This isn't avoidance — it's quality control for your own thinking. When you're distracted and rushed, you give worse answers. When you pause, you also create space to ask: is this mine to solve, or does it belong to someone on my team?

John extends this to how teams bring problems: train people to come with clarity — here's the problem, here's the challenge, here's some potential solutions. That way the leader can triage effectively in a short time instead of getting pulled into an unstructured conversation that eats an hour.

About John Whitt

John Whitt is a leadership strategist with 30+ years of business transformation experience, from managing $500 million construction portfolios at companies like CB Richard Ellis to coaching small business owners. He's the author of Checkmate!: Winning Tactics for Translating Ideas Into Money and creator of the Whole Life Leadership experience.

You can link with John Whitt on LinkedIn.

Apple Intelligence 2.0 and Siri AI

Apple used the WWDC26 keynote to introduce a new generation of Apple Intelligence that expands on last year's generative features. The upgraded system runs on a privacy‑preserving architecture that uses on‑device models and Private Cloud Compute. The new Siri AI is deeply integrated across iPhone, iPad, Mac, Apple Watch and Vision Pro. Siri can now understand what's on screen and draw on personal context to search across messages, photos, emails and third‑party apps. When needed, it reaches out to the web to provide up‑to‑date answers. A dedicated Siri app lets users revisit past conversations and syncs history across devices via iCloud.

Apple Intelligence also powers new experiences across the system. Spatial Reframing in Photos lets users re‑compose pictures after they are taken. Image Playground can generate high‑quality images, and Messages and Mail offer AI‑driven suggestions for replies and reminders. The intelligence features support multiple languages, run on devices with A17 Pro or M‑series chips and will be available in the fall with iOS 27.

Foundation Models and Core AI Frameworks

Foundation Models framework

For developers, the most transformative announcement is the Foundation Models framework in iOS 27. It is a native Swift API that gives apps direct access to the same on‑device language model powering Apple Intelligence. Developers can switch between Apple's model, cloud models (such as Claude or Google Gemini) or any provider that implements the new Language Model protocol. The framework supports multimodal prompts, allowing apps to pass images alongside text and use Vision tools like OCR and barcode readers. Dynamic Profiles let developers swap models, tools and instructions during a session so their app's behavior adapts to the user's needs.

Smaller teams benefit from cost‑free access: developers enrolled in the App Store Small Business Program and with fewer than 2 million first‑time downloads can use Apple's next‑generation models on Private Cloud Compute at no cloud API cost. A new Evaluations framework helps verify that AI features behave correctly across dynamic conditions.

Core AI

Where Foundation Models provides access to generative models, the new Core AI framework lets developers bring their own models on‑device. Core AI offers a memory‑safe Swift API and accompanying Python tools to load, specialize and run models entirely on Apple hardware. It delivers zero server dependencies and zero token costs while supporting everything from compact vision models on iPhone to multi‑billion‑parameter language models on Mac. Core AI integrates with ahead‑of‑time compilation, a visual tensor debugger and optimization tools to convert PyTorch models for the Core AI runtime. Apple noted that Core AI is optimized for Apple Silicon and also powers Apple Intelligence experiences across the system.

App Intents and System‑wide Intelligence

The App Intents framework has been expanded so Siri and Apple Intelligence can perform more actions with third‑party apps. Entity schemas allow an app's content to be indexed in the Spotlight semantic index, making it discoverable by Siri. Intent schemas define actions that users can take naturally without pre‑defined phrases. A new View Annotations API maps views to entities so users can reference on‑screen content conversationally. Apple also introduced an App Intents Testing framework to validate integrations without UI automation.

The Platforms State of the Union elaborated on how App Intents works with the System Orchestrator, Spotlight semantic index and the App Toolbox to route user requests across apps. Siri AI can now surface your app's content and actions through widgets, the Action button and voice interactions, and these integrations automatically improve as Siri learns new languages or dialects.

Liquid Glass Design and Platform Improvements

Liquid Glass refinements

Last year's Liquid Glass design language unified Apple's platforms. For 2026, Apple tuned it to improve readability and depth. Liquid Glass now diffuses complex content more effectively and adds a darkened edge with brighter specular highlights. Users can personalize the effect with a slider ranging from ultra‑clear to fully tinted. Apps already using Liquid Glass get these improvements automatically without recompiling. The design adapts to accessibility settings (e.g., reduced transparency and increased contrast) and introduces colored sidebars, refined toolbar behavior and improved icon rendering with refraction effects.

Resizability and SwiftUI

With iOS apps appearing on iPad and Mac via iPhone Mirroring, Apple introduced resizable iOS apps. Rebuilding with the latest SDK automatically opts an app into resizability. SwiftUI and auto layout provide basic support, while the new Resizable iOS Simulator and Previews let developers test across sizes. A built‑in agentic coding skill helps find and fix resizability issues.

SwiftUI itself gains richer interactions such as reorderable containers, allowing drag‑to‑reorder lists and grids with minimal code. SwiftUI's improvements target speed, dynamic interactions and new capabilities, making it easier for developers and encouraging migration from cross‑platform technologies.

Xcode 27: Enhanced Productivity with Agentic Coding

Apple’s flagship IDE saw major updates. The new Xcode 27 focuses on two pillars: intelligence and daily usability. Performance improvements make projects load faster, debug sessions more reliable and the console capable of handling heavy logging. Xcode 27 is 30 % smaller, now runs only on Apple Silicon and downloads agents and documentation in the background to stay up‑to‑date.

Personalization options now sync settings via iCloud. When setting up a new Mac, Xcode imports preferences and Git configuration automatically. Creating a new project jumps straight into the editor, deferring file names and bundle IDs until later. Developers can customize the toolbar and choose from new color themes such as Emerald, Neon Noir and Coral Reef. Xcode Cloud builds are up to twice as fast and require no App Store Connect setup, supporting Apple Vision Pro and Metal apps.

A Device Hub merges the simulator and physical device management into one interface. It supports pinch‑to‑zoom, two‑finger scrolling, dynamic resizing and testing of various system settings like dark mode and text size.

Agentic Coding

Xcode 27 weaves coding agents into every layer. Agents can plan, implement and test features. Developers start by describing their idea; the agent generates a plan, asks clarifying questions and produces code and UI previews. Agents can run tests in the simulator, localize strings, and even identify and fix crashes based on crash logs. Xcode 27 includes specialized skills—for SwiftUI, accessibility and performance—that help agents produce high‑quality code.

Other Notable Frameworks and Tools

• Platform improvements: The new SDK makes apps launch faster and adds enhancements across frameworks, media, search and accessibility.

• Game Porting Toolkit 4: Features agentic coding skills for Metal and game development, speeding up ports to Apple platforms.

• Music Understanding framework: Enables six‑dimensional audio analysis and works with NowPlaying to integrate playback with Lock Screen, Control Center, Dynamic Island and CarPlay.

• Photo and camera APIs: Core Image RAW processing APIs (version 9) provide improved sharpness and color, and new APIs support high‑resolution photo capture and Center Stage front‑camera features

An ersatz CSS tutorial for people who need to style a web page, but aren’t web developers. I am a wrong person to write this kind of thing, as I have neither the time, nor experience. I’d much rather read a book about this. Alas, I had to learn all this stuff from trawling MDN, so perhaps it is valuable to document what I have so far.

CSS, HTML and Web APIs are truly vast, and it takes a career to become a professional. The good news is that modern web has a reasonably-sized, learnable subset which is enough for simple tasks like a programming blog or a simple GUI. I haven’t seen a resource that teaches just this subset, but it’s not too hard to figure this out. The bad news is that there’s also a nasty set of gotchas, which will mess up your page, which you won’t suspect to exist, and which will need days of debugging to figure out. Still, it’s not that bad. I am quite happy with the styling on this site, and it’s only about 200 of readable CSS.

Good: HTML5 semantic tag names
It’s worth looking through MDN Elements Reference. There aren’t that many elements, and things like main, article, nav, kbd make it much easier to structure your page. Less obvious:

• ul for any kind of list, like site’s sections in header > nav.
• details for table-of-contents (check the source of MDN).
• dl/dt for list of pairs.

Bad: Wrappers
If you “View Source” on any “real” website, you’ll notice that everything has layers and layers of wrapper elements, so you might be tricked into thinking that wrappers are how you solve layout problems. I can’t really agree or disagree here, as I never wrote “production” CSS, but, in my experience, it’s much easier to understand if you do the opposite — restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have.

Bad: Layout
This one is not an exclusively Web problem, layout is a struggle in every GUI framework I know. Imagine a fixed sized raster image, and a paragraph of text describing it. There are many ways to arrange these two elements on the screen’s rectangle. Generally, for every given width and height, you can do a decent job, as long as the total area is enough. A typical GUI is a hierarchy of such boxes, with a lot of “layout freedom”. The problem though is that layout of each box affects the layouts of all other boxes, as you generally want all boxes to meet exactly, without gaps and overlaps. An important negative realization is that the layout algorithm doesn’t exist. There isn’t a fully general solution to positioning and sizing GUI boxes. Rather, different systems use different sets of heuristics to do the job, from simple RectCut, to fully general constraint solvers, with everything in between. It is hard to get the mental model of how layout works, in general. So, don’t think “how can I do my layout in a given system”, think instead “what possible layouts are allowed by the system”.

Bad: Browser defaults
Let’s start with a bare (but still semantic) HTML markup of a blog article, without any CSS. If you open it in a browser, it will show something. The content isn’t unstyled — the text is of a certain color, font and size. Headers are bigger than the main text, links are underlined, etc. These are the default styles of your browser. They are helpful! The problem is that these styles differ between the browsers. So, even when you add your own CSS, and the end result looks fine in your browser, I might see something different, because you might rely on a browser default, without knowing it. The last bit is the killer here — the problem is in something you didn’t write.

The general solution here is a CSS reset, or normalization — starting your CSS with an explicit set of rules, overriding defaults. Not because defaults are inherently bad, because they are inconsistent. I don’t know which set of rules you need to override in practice, it’s a good idea to compare several existing CSS resets.

This touches on the big question: should you style your web page? There are two competing views of the Web platform — some people treat it as a flexible, adaptive, primarily visual medium for expressing design, others would prefer if the Web focused on delivering the content, allowing each user to customize the presentation. My personal answer here is pragmatic — by default, an unstyled page is poorly usable and looks bad. I would have preferred the world where CSS-less pages were readable as is, but, in this world, I think it is helpful to style the content. At the same time, it’s a good idea to allow advanced users to bring their own CSS. Make sure that your HTML markup is reasonable, that you don’t overfit your HTML to CSS (vice-versa is fine), and that your page functions in reader mode.

Good: Classless CSS
You can’t reset styles to true neutral nothing: if you make the text invisible (white or transparent), it is still a style. So you might as well embrace it: after reset, style common HTML elements directly. For example, to set your favorite font for all code snippets:

code { font-family: "JetBrains Mono", monospace; }

If you use main, header, footer, nav tags you can set the overall page layout without writing any CSS selectors. This of course requires making assumptions, in CSS, about the structure of your HTML, but, like, this is your HTML and your CSS, you can do whatever, and, if you don’t like the result, you can always change it!

Bad: CSS selectors
In programming, we collectively came around to distrust inheritance and prefer composition. Default CSS is like supercharged inheritance, each design element on your web page is affected by multiple rules, and you can always “monkey patch” existing elements by appending to your CSS. There’s an unfortunate gap between CSS affordances, and what you actually want to do. The two reasonable approaches are:

1. Conclude that CSS selectors add abstraction capability along the wrong axis, and stick to classless CSS and inline styles, using something like Tailwind to make writing inlines prettier, and something like JSX (or any other templating engine supporting composition) to avoid repetition in HTML.

2. Use CSS nesting to avoid writing “far reaching” selectors and style component-per-component:

header { /* Site Header */
    margin-bottom: 2rem;
    & nav {
        /* Styles, specific to nav in the Header. */
    }
}

Bad: box-sizing
UIs are recursive rectangles, layout is the process of figuring out where each rectangles goes, and it is determined by the sizes of rectangles themselves. So, understanding what is the size is quite fundamental. Sadly, by default the definition of size in HTML is very unintuitive: element’s width and height do not include element’s border and padding, which leads to surprising results: everything looks perfect at first, but increasing padding somewhere shifts the entire layout unexpectedly. For this reason, * { box-sizing: border-box; } deserves to be the first line in your CSS reset. It makes elements encapsulated, such that adding borders is a local-only change.

Chaotic Good: margin collapsing
Suppose you want to have a 8px gap around an element. You would think that you need to set the padding property. But that would be wrong — if you have two such elements next to each other, the gap between them would be 16px. The paddings would add, creating a visual gap larger than intended. You want something more akin to social distancing, where if one person is more introverted, this person’s bigger radius of exclusion is what defines the distance. And that’s how the margin property works. Two neighboring margins are combined using max rather than sum. Margin collapsing is very useful, but it can surprise you. E.g. I think child margin can stick beyond parent’s? To be honest, I don’t have a good intuitive understanding of margins, but I know enough to at least identify when it is the problem.

Margins are also one of the indirect inspirations for this post. In

Moving away from Tailwind, and learning to structure my CSS

Julia Evans writes that you generally don’t want to set margin on an element, and should rather let the parent control the inter-element margin of the children, using the so-called owl selector:

section > *+* {
  margin-top: 1rem;
}

That is, add margin to all section’s children exempting the first one. I didn’t know that! And, given all the pain that margin gave me so far, I actually get why you want to do this, and why this is a good idea. But it bugs me that you can’t learn that without becoming “professional” web developer, or reverse-engineering someone else’s CSS framework.

Bad: Default (flow) layout
Layout in general is tricky, because there’s no universal “layout algorithm”, just a bunch of special cases. But what does HTML actually do? The default layout algorithm I think goes back to the origin of HTML as a language for documents, and overfits a use-case of producing papers — mostly text content with some illustrations, where the text can flow around the pictures. That’s actually what you want for the main body of text of your blog, but, as soon as you want to actually control the spatial arrangement of the elements on your page, you want something different, for example…

Good: flexbox
This is really what separates modern web-development from the olden days, where you’d need a CSS PhD or a full-blown opaque CSS framework to be able to say “this goes to the left, and this goes to the right”. This layout allows you to arrange a series of elements either vertically or horizontally, adapting to the available space. It is rather complex and I can’t use flexbox without referencing MDN all the time, but usually I am able to get things done in the end.

Bad: responsive design
Modern CSS allows querying screen size, and implementing conditional logic based on that — a design that “responds” to user-agent constraints. This probably what you should use for “real” CSS, but note that HTML is inherently responsive. Unlike PostScript (PDF), it will automatically reflow the paragraphs when you change window size. So, it’s a good idea to avoid writing explicit responsive rules, and just rely on layout to do the reasonable thing. For example, this blog looks OK on mobile, tablet and desktop without any explicit @media queries. Unconditionally setting max-width on the main column of text is all that it takes.

Lawful Evil: pixels
1px does what you want, but not what it says. It’s not a size of one physical pixel on your screen. Rather, it’s a measure of visual angle. That is, 1px should look perceptually the same on any screen, and it is converted to different number of physical pixels, depending on the screen size, its pixel density, and the typical viewing distance. So you can just size everything in pixels, without thinking about different displays’ pixel densities. It gets weirder. CSS allows “real” units like centimeters or inches, but they are also angles, because everything is defined in terms of pixels.

Doubleplusungood: font-size
Flexbox is a good way to layout UI-elements. Flow layout works ok for laying out paragraphs of text. But what happens on the level of individual lines and glyphs is, in my opinion, a train wreck and a noob trap. Let’s start with the basics: if you write font-size: 16px then 16px is the size of what? Sadly, the answer is “nothing in particular” — this is a size of a virtual box around the glyph, but the box isn’t tight, and the size of the glyph varies, depending on the font. Luckily, font-size-adjust property can fix it, and make font-size consistent across fonts. See these two posts for details:

• font-size-adjust Is Useful
• Font size is useless; let’s fix it

Though, at the moment font-size-adjust seems to be very niche, so, while personally I’d put font-size-adjust: ex-height 0.53; right next to box-sizing, few pages do that.

The next issue with font-size is a thorny question of defaults. The good news is that it’s one of the properties that is fairly consistent across browsers, with 16px being the overwhelming default. The bad news is that, depending on the font, 16px can be on the smaller size. Not completely illegible, but very close to the lower bound. What’s worse, some default fonts are particularly small. For example, on Apple, font-family: serif looks much smaller than sans-serif, and is almost uncomfortable to read at 16px.

Can you just set font-size: 18px or whatever works best for your chosen font? I think the answer is yes, but there are some caveats to keep in mind. Refer to Accessibility: px or rem? for details. The issue is that modern browsers support two ways of making text on a page bigger:

• Zoom, which has a dedicated UI element, shortcuts/gestures, per-page persistence/overrides and a global default.
• Changing default font-size, a global setting buried deeply in the configuration page.

Setting font-size in your CSS disables that second approach.

Taking everything together: don’t assume that text on your page will be readable by default, check different configurations. Set font-size-adjust to reduce the number of degrees of freedom and to pin down the meaning of font-size. If the result looks fine with your chosen (or your user’s default) font and default font-size of 16px, then you are done. Otherwise, set font-size to a bigger number. Afterwards, check that the page is readable in reader mode as well.

Bad: line-height
Despite the name, line-height doesn’t set the height of a line. It is a height of a run of glyphs, set in the same font. The two coincide when all the text is in the same font. But if you have, e.g., some words set in monospace font, you are in for a surprise. While font-size-adjust fixes the size of a glyph inside the box, it still leaves its relative position unspecified. So, when two runs of text in different fonts are aligned vertically to share the baseline, their line-height line-boxes get shifted relative to each other: one sticks below, one sticks above. The line height overall becomes larger that what you’d expect, as it is configured as a union. See

Deep dive CSS: font metrics, line-height and vertical-align

for a thorough explanation of this effect.

Bad: vertical rhythm
If you google long enough this cluster of problems, sooner or later you’ll come across the idea of vertical rhythm, that you should make sure that lines are in the same relative position across different paragraphs, even if you have headings, images, and what not. As if there’s invisible lined paper behind your web-page. As far as I can tell, this is pure voodoo and is not useful. If you do two-column layout, then you want lines on opposite sides to align, but it makes no sense to jump through hoops for a single-column layout (hat tip to @chrismorgan).

Bad: word-break
The genius of the flow layout is its dynamism. It takes a moment of reflection to appreciate the technical marvel of text breaking itself neatly into lines as the window is resized to be narrower. Getting that to work for the first time ever in the world of durably printed text must have felt incredible. But the magic has its limits — you can only break the line at the whitespace, or at the hyphenation points. And some long spans, like inline code or URLs, might be unbreakable. This leads to overflow annoyance on mobile devices, something you notice only after you publish your work. There’s no one trick to fix it, but some tips are available here: Against Horizontal Scroll for details.

And … that’s all I remember so far? I reiterate my request for someone to write a short 100-page book explaining just enough of HTML&CSS to make a simple blog without getting collapsed by the margins!

Data protection by design and default

Under GDPR, both data privacy and data protection are two key regulatory requirements. Article 25 of the GDPR stipulates that when organizations are designing their products, systems, and services, they must implement appropriate technical safeguards and organizational measures. This is achieved by prioritizing data protection in every stage of the project, in the default settings and in processing activities.

Data privacy refers to ensuring data subjects themselves can have control over their data, by managing who processes it and for what reason. Data protection on the other hand refers to keeping data safe from unauthorized access. Both are important for customer trust and legal compliance. When TikTok was recently fined by the Irish Data Protection Authority for failing to disclose and adequately protect user data transferred to China, for example, they failed to maintain data privacy and protection.

This blog will explore further the concept of data protection and how it can be accomplished through design.

Why is data protection important?

Data protection by design is the process of incorporating data protection principles into the development and implementation of an organization system, services, products, and general processing activities in the early phases of development. It’s best when the strongest data protection settings are set as the default in the product or service. Organizations across all sectors of the economy should incorporate data protection wherever possible. This will help to boost their overall security posture, maintain regulatory compliance, and enhance their credibility. Further, it can help organizations avoid costly fines for non-compliance.

How can my organization implement data protection by design?

To implement data protection:

• Conduct privacy impact assessments to determine potential privacy risks associated with your information systems and services.
• Incorporate data protection in the design phase of your data processing activities, information services, and systems by implementing encryption, secure authentication, and access controls.
• Set default privacy settings that are in line with data protection policies to ensure personal information is protected by default, even if users don’t change the settings themselves.
• Provide data protection training and education to employees so they understand the importance of protecting personal information and how to maintain the measures you’ve set in place.
• Regularly review and update your data protection measures to ensure they remain effective and relevant for the activities that the company undertakes.

Principles of data protection by design

Data protection by design is founded on seven core principles of GDPR for lawful data processing:

1. Lawfulness, fairness, and transparency: Lawfulness establishes a legal basis for data processing, such as the consent of data subjects. Fairness implies that organizations must not use data in a manner that is detrimental or unfair to an individual. Transparency is openness to data subjects about how their data is being processed in a clear and concise manner.
2. Purpose limitation: Personal data should only be used for specified, explicit, and legitimate purposes, not used in ways that have not been consented to.
3. Data minimization: Ensure that only the necessary data is collected from data subjects.
4. Accuracy: Personal data that’s been collected must be accurate and up to date. Data subjects also have the right to have incorrect data rectified.
5. Storage limitation: Personal data should be retained only as long as necessary for the purposes for which it was processed. You agree that you won’t keep data after it’s no longer needed for the purposes you stated to users.
6. Integrity and confidentiality (security): Implement appropriate technical and organizational measures, such as encryption, to ensure the confidentiality, integrity, and availability of personal data.
7. Accountability: Organizations must take responsibility for their data processing activities, conduct data protection impact assessments, ensure data protection by design and default, and demonstrate compliance with the other six principles of GDPR.

Conclusion

Thank you for reading! In today’s data-driven landscape, it’s essential to integrate strong data protection capabilities into your projects, systems, services, and products. By governing how data is collected, processed, and stored, you ensure that information is handled only when necessary, minimizing risk while promoting accountability, transparency, and compliance with regulatory standards.

Syncfusion^® tools are designed with GDPR compliance in mind, reflecting a strong commitment to data privacy and security. With robust safeguards in place, Syncfusion products help ensure that personal data is encrypted, preserving its confidentiality and integrity at every stage.

For our existing customers, the latest version of Essential Studio is now available for download from the license and downloads page. If you’re new to Syncfusion, we invite you to explore our offerings with a 30-day free trial and experience the value firsthand.

If you have any questions, feel free to connect with us through our support forums, support portal, or feedback portal. We are always here to help!

A guest post by Red Pens and Playwriting's Jordon Jones 

Salutations to you all! 

This is not your usual writing guru speaking; Emily has very kindly allowed me a slot to talk about something very near and dear to my heart: syntax. I know, it doesn't sound all that exciting, does it? Not compared to things like story arcs and characterisation and worldbuilding and literary techniques, certainly. It's easy for us to want to devote time and effort to examining the fun elements of storytelling, but it's also important to remember that telling stories is, first and foremost, a type of communication. Whatever story we want to tell, in whatever manner we tell it, will greatly benefit from being communicated effectively through things like grammar and syntax. Our artistic medium is words, and we need to be as competent with them as a visual artist needs to be with lines and circles.

For anyone who isn't completely sure what "syntax" is, I will define it here as the way that words are arranged in sentences. It includes things like how long a sentence is, the number of clauses it contains, whether it is a grammatically correct sentence at all, and the order in which information is presented. There's a lot more to it than just correctness—you can use your understanding of syntax to influence the way your reader experiences the text. In fact, you're probably doing this already! 

Let's explore a few ways that this influence takes place. For best results, pull up a piece of your own writing to refer to as we go and see what you notice. How does the syntax of your writing affect the way it reads? Where are you purposely playing with it to affect the reader? Are there opportunities where you can alter your sentence structure to improve the text?

Manipulating length

One method of syntactical manipulation that is easy to spot is sentence length. This is related to complexity, because longer sentences can fit more complications in them, but it's not a 1:1 correlation, so I'll discuss them separately. The main effects of length, in particular, are rhythm and pacing. Here are a couple of examples to compare:

Maria's heart was hammering in her chest as she approached the forbidding door to the chalet. The handle of the battered suitcase she held felt slick and clammy with sweat, slipping easily from her grasp with a thud. Slowly, reluctantly, she raised a trembling hand to the knocker.

Maria stood before the chalet door. Her heart hammered against her chest. Sweat coated the handle of her battered suitcase. It slipped from her hand with a thud. Slowly, she raised her hand to knock.

You can see the difference in rhythm pretty clearly here: with the first set of sentences (probably an average length for most people, and certainly normal for me), there's a smoother flow, whereas the shorter sentences create a choppier effect. You can use this manipulation of rhythm to adjust tension—doesn't that second example feel so much more anxious, even without the visuals from the adjectives? A single short sentence can also be a good way to punctuate or interrupt your flow to draw attention to a particular beat. Like so. On the other end of the spectrum, check out this much longer sentence:

With her heart hammering in her chest and her battered suitcase slipping in her clammy, sweat-drenched hands, Maria approached the forbidding door to the chalet, at which point the suitcase finally dropped to the ground with a thud, leaving her hand free to reluctantly creep up towards the door knocker.

We've gone beyond having a comfortable flow here, and it feels more like we're skimming across the action than like we're engaging with it. This could be a useful way to convey a sense of too much happening at once or of emotional overwhelm, where there isn't a chance to pay much attention to the details. Too many excessively long sentences can lose a reader's attention, though, so be careful with them.

Pacing is essentially rhythm on a larger scale, looking at full scenes rather than individual sentences and paragraphs. Within the scene, you'll want your sentence rhythm to expand and contract along with the emotional beats, but when you zoom out a bit you will probably notice that most of the sentences tend towards being longer or shorter, and that's a big part of the pace. Scenes with lots of quite long sentences feel less urgent, perhaps more thoughtful or introspective. When you put more short sentences together, the scene feels more focused, like a climax or action sequence.

Manipulating complexity

As I said, sentence complexity ties in pretty closely with length, as complex sentences are often long as well. However, the effects of complexity don't necessarily relate to those of length, even if they do like to exacerbate each other.

Before we get any further, I want to provide a few definitions to help with this next bit:

• Clause: a collection of words and phrases containing both a noun and a verb—if it can work as a full sentence, it is an independent clause, otherwise it is a dependent one
• Simple sentence: a sentence containing only one independent clause
• Complex sentence: a sentence containing an independent clause and at least one dependent clause
• Compound sentence: a sentence containing more than one independent clause (if there are also dependent clauses, that makes a complex-compound sentence)

Now that we have that sorted, what are the effects of complexity in sentences? Clarity, mainly. Simple sentences are very straightforward, and don't tend to have a lot of fluff to them ("Maria stood before the chalet door."). Complex and compound sentences add more context to the sentence, and the reader starts to make inferences from the way clauses are connected ("Maria's heart was hammering in her chest as she approached the forbidding door to the chalet." Ah, something about the chalet is making her nervous!). The more connections between different clauses the reader has to draw in one sentence, the greater the chance that something gets missed or misunderstood.

I find myself constantly breaking up and simplifying sentences in my own work, because while I think all of the context and connections together at once, I've learned that that is not a great way to communicate. Readers, including me, need to make connections one or a few at a time, not in a great lump. Think about which pieces of information have the strongest links to each other; these can be joined in a complex sentence, such as the chalet affecting Maria's heartbeat. Points which are closely tied to each other but are more distinct or complicated might be better in a compound sentence, such as "Sweat coated the handle of her battered suitcase, and it slipped from her hand with a thud." If the information is not strongly connected to anything else, or if you really want it to stand out, put in a simple sentence.

The complexity of your sentence structure also contributes quite strongly to voice, whether in relation to narration or character dialogue. If you struggle with creating distinct character voices, one thing that may help is looking at how they structure their language. A preference for simple sentences might indicate a focused or taciturn nature, where the character speaks right to the point. They might also be used for a child or non-fluent speaker, who might not have developed the language skills for more complicated speech. Conversely, characters who use a lot of complex and compound sentence constructions are often read as being more studious, analytical, talkative, or maybe just really neurodivergent.

Manipulating order

The last element of syntax I want to talk about today is word order. This is something that I suspect a lot of writers don't think very hard about unless they have a history of writing in verse. As a matter of fact, absorbing Shakespeare's technique of playing with phrasing and writing sonnets in his style was a great way for me to explore ways of manipulating the way that a sentence or phrase is ordered. In the context of sonnets you have to order words to fit the rhyme scheme and metre; you don't need to worry about those elements so much in prose writing, but there are other ways in which word order makes a big difference.

I read a fantastic article at university called "The Science of Scientific Writing", by George D Gopen and Judith A Swan, which completely revolutionised the way I think about sentence structure. Their article is primarily aimed at scholars in STEM subjects trying to communicate their research, but I think their concepts can be applicable in any form where you're trying to convey potentially complex information, from business emails to worldbuilding exposition. The whole article is great, but the particular ideas I want to point out here are the two ends of a sentence: the topic position and stress position.

The topic position in a sentence is its beginning, and this is your chance to make sure your reader is prepared for the rest of the sentence. It's where you generally introduce the sentence's subject, along with whatever context you need to get out of the way. You may also link back to the previous sentence to keep up the momentum of the piece. In simple terms, the topic position introduces the idea and sets the reader up. Compare the following, and note a) which is easier to follow, and b) what the focus of each sentence seems to be:

Before the war, I lived in a castle overlooking the river with my uncle.

A castle overlooking the river is where, before the war, I lived with my uncle.

The other end of a sentence is called the stress position, and that's the bit that readers will emphasise and remember most. This is where you want to give your reader closure to the idea that you introduced and tie things off, but also where you want your most important or effective takeaway to be, whether that's a piece of information or an emotional effect. The last thing we read is what sticks in our heads, so you want to make it good. Here are a couple more examples to illustrate the idea:

"I understand your problem, but I don't care," said the general with a flick of his cigar.

"I understand your problem," said the general with a flick of his cigar, "but I don't care."

This idea of topic and stress positions isn't just confined to sentences, either; you can use it to organise sentences within a paragraph as well, or to order concurrent POVs in a section of a novel. You just need to think about two things: what does the reader need to know first, and what do you want to leave them with before you move on?

Red Pens and Playwriting is a blog for writers of all levels of experience that discusses a variety of topics relating to language and literature. It is written by Jordon (Jojo) Jones, who has a distinct passion for the technical craft of writing and constantly insists that knowing the rules is important because it enables you to break them on purpose.

Shh... Jordan doesn't know I'm putting this here.

Jordan just published an excellent manual called Red Pens 101 on the basics of grammar with heaps of examples, a lot of cat references, key point summaries at the end of each section, and one rickroll. Take a look. ~EM

Find it on Red Pens and Playwriting

~~~

Image Credit: Via Library of Congress. Albrecht Durer "St. Anthony (1519) Engraving B 58. From the Impression in the British Museum." in Eckenstein, Lina, Howard Coppuck Levis, and Lessing J. Rosenwald Reference Collection Dlc. Albrecht Dürer, / by Lina Eckenstein. , 1902. [London, Duckworth & co] Photograph. https://www.loc.gov/item/03016535/. Image cropped and converted to black and white.