To solve this and make the conditions a bit more flexible you can use a filter variable and extending it a little.

So now I can send in the slug and category into my function and create the conditions dynamically. This would be even more useful in this example once you want to send in an array of slugs or categories and create the where condition in your SQL

public function getPosts(string $slug, string $categories)
{
    $posts = new $posts();

    $filter = [];
    $filter[] = ["condition" => "slug = '{$slug}'",
                 "type" => "and"];
    $filter[] = ["condition" => "category = 'Holidays'" ,
                 "type" => "or"];

    $filter = $this->buildFilter($filter);


    $posts->select("title,excerpt,slug,content")
        ->where($filter)
        ->asResult();
}

So here's how I've tackled the issue of building out the filter conditions. I create a long string and add the Condition specified in the $filter array (above code).

An important bit is that I don't add the condition when the $where variable is empty.

public function buildFilter(array $filters)
{
    $where = "";

    foreach ($filters as $filter)
    {
        switch (true)
        {
            case ($filter["type"] == "and"):
                (empty($where))
                ? $where = $filter["condition"] //true don't add AND
                : $where .= "AND {$filter["condition"]}" //2nd value add the AND
                ;
            case ($filter["type"] == "or"):
                (empty($where))
                ? $where = $filter["condition"]
                : $where .= "AND {$filter["condition"]}"
                ;
        }
    }

    return $where;
}

That's all there is to it.

Using ZealDocs is a great time-saver instead of having to look up documentation for things like HTML, Bootstrap, PHP, JS and more.

The added bonus is that you have documentation to continue coding if your Internet connection goes down.

Another technique has been to reference documentation from the IDE. I've used Jetbrains IDEs extensively for simple reference as I type.

But every, so often I'm looking for full reference and zeal is just perfect for that.

Download ZealDocs here

In adopting VUE and REACT I've noticed that we're effectively doing in JS what a Back-end language like Python, PHP, Node or Ruby would do rather well. So effectively we're duplicating the role and relegating the back-end to an API with a Database connection.

So now we have routers and state etc all running in the front end. No matter how you spin it, running business logic in the front end is a bad idea. As a result you're going to need a bit of both on such a project to keep sensitive data out of your front-end code. On some projects this can make perfect sense.

Then we have the issue of State which becomes rather complex when you're trying to run a webserver in the browser. All of which is perfectly liable to drive you to more abstraction.

Then there's the issue of how heavy things become after a bit. So if you've been writing a bit of VUE or REACT you reach a point where there's too much JS to be practical. So you need to render down to HTML on the Server side and then just bring in dynamic bits. So effectively you're using React and VUE as a backend and front-end language at that point. Unless you're doing something rather special this is no different from using AJAX and a Back-end language. Except that you've now moved all your code into JS and added heaps of complexity into the mix.

So am I saying front-end frameworks are bad? Not necessarily, but you do have to consider the budget implications of writing more code to do the same thing. For me the benefits don't generally outweigh the cost of doing so just yet.

When I'd use a front-end Framework

There are cases where a front-end framework makes complete sense.

• You want a highly interactive site.
• You're not concerned with how much data your end user will need on his mobile phone. React and Vue make API calls just a bout every second. So unless you're using GraphML you're going to run up bill for your end user for sure.
• You have a customer with a very large budget
• You have a very large team

Thoughts on VUE

I've used React but have come to enjoy the syntactic sugar Vue adds on top of all this. In my opinion it's the most approachable of the Front-end frameworks. It's ability to add interactivity in your code without taking over your codebase until unless a page's complexity warrants it, is a sure win.

When I'd just drop in bits of JS for interactivity.

On an average project you may just need a little interactivity. Similar interactivity can be achieved with a little JS or Jquery or another JS library without making things more complex than they really need to be.

Conclusion

Each project is different, but in the end it comes down to what makes sense. If you are able to keep things simple you can deliver more of what the client wants and spend less time driving yourself to Abstraction.

I recall the Manga graphics and names to different sections of the code back in 2014 when I first saw Tina4.

I've been working with Andre van Zuydam full time for the past 3 weeks. In this time I've gotten to know Tina4 toolset up close.

One of the key things that I've found striking is that Tina4 does not abstract work unnecessarily by adding NPM scripts. There are some Composer scripts for most Tina4 tasks. Everything else is done either in the browser or in PHP. Of course if you want to do Ajax you'll need to write some JS.

What's included

Out of the box Tina4 includes quick ways to get you up and running in a lightweight way when you want to build a new PHP app. Its installable with Composer.

Talking about includes. Tina4 makes in unnecessary to add include lines in any of your files.

Caching by default

Caching is included out the gate with PHP Fast Cache. There's no config required.

SASS Support

No need to add extra build scripts unless you're building very complex SASS hierarchies. Drop you SASS in the SASS directory and run your APP. Your SASS builds to CSS without extra commandline tasks to manage.

Migrations

Migrations in Tina4 are brought right back to SQL. It's been a pain point to me that many frameworks so abstract migrations that people forget that they are working with SQL.

In Tina4 you write your migrations in the browser which creates the required migration files that create a record in the migration database. Execute migrations by calling a migration endpoint in your browser. You see the output directly. Migration files are editable since they really only contain the SQL you entered the browser. If you can write SQL you can do migrations immediately. This is a benefit that is easily overlooked unless you've felt the contortion caused by Frameworks that abstract migrations and other bits for the sake of abstraction.

ENV Support

Naturally any modern workflow needs ENV support out the box.

Routes

Routes can be written in different files as long as they are stored in the Routes directory even if they are sorted in subdirectories. This makes managing routes much simpler in practice.

Routing in Tina4 is similar to what you'd get to know in Frameworks like Laravel. You should remember that Tina4 is a much lighter stack in kb not features.

ORM

The Tina4 ORM supports Firebird, Mysql, Sqlite right out the gate. So expect very similar syntax for each Database you interface with

If you write your database column names according to convention then you get to include very minimal information in an ORM class.

$firstName = "Bob"
$user = (new User())->select("*")
                    ->from("user")
                    ->where("first_name = {$firstName}")
                    ->asArray();

API

Consuming and generating API's are easy in Tina4.

Consuming API

Tina4 Comes with API functions that make consuming rest endpoints as simple as can be. Even easier than using Javascript Fetch(). And you can still use JS Fetch if it catches your fancy.

Creating an API

Tina4 comes with a one line CRUD generator that you include in a new API endpoint file. Once you fire up the app in the browser Tina4 scaffolds all the crud routes for an ORM Object onto the API endpoint of your choice. One line of code, and your API works out the box. It's all still written in PHP.

ORM classes cleverly extends to CRUD routes that are widely used in Tina4 to create API's with a single line of code. A CRUD route is linked to an ORM object, if you post a form containing inputs that match the ORM fields you don't need to write any code to create or update records. This works so seamlessly that at first glance it almost feels like magic.

Templates

Templates are elegantly integrated in Tina4 using Symphony's Twig template engine with some custom work where it matters.

Templates can run without any routing if there is no route with the same name. This makes for convenient testing and less hassle when you have a route that really only serves up a page.

HTML Functions

Tina4 includes a library of php functions that can generate HTML right out the box.

There's an underscored function for every HTML class imaginable. So you literally can generate valid HTML from code

Admin Dashboard

Tina4CMS is probably the best kept secret when it comes to Tina4. It creates a fully functional Admin Dashboard with minimal lines of code. You get Templates and Crud Grids generated with create, edit, delete, search and export out the gate.

Login is included as well out the box to get your Admin Dash functional as soon as possible. With a little tweaking your Admin dashboard works exactly like you want it.

Ajax

Tina4 comes with a JS helper library to post and get page parts, modals and more from api endpoints

Conclusion

Simplicity is the ultimate complexity. Tina4 is a flexible and rapid starting point to any PHP project. As I've worked with it I'm fascinated by how simple Tina4 makes things that are often very complex in the PHP world.

If you've been frustrated with how Frameworks abstract things away too far, Tina4 is a good place to invest your time. There's a Slack group where the community join in and ask and answer questions. Along with Documentation on how Tina4 works.

I've been contributing to expanding the documentation in the past 3weeks.

I'll be posting some insights on the blog. So keep an eye for more on this soon.

Recently a client asked me to design them a template for a signature with complex overlapping images. On the web that's a very easy thing to do. But in the email space layers are poorly supported.

Quirky Mail clients

Even after years I still find it odd that mail clients have grown more quirky in their support of web standards. We're all still coding like it's the late 90's for email.

It's 2021 and we're really in need more modern features on email clients. But the thing we need most is standardized support between mail clients.

Interestingly Mozilla just dropped several critical CSS features that enabled responsive designs. So Responsive mail now gets to display in mobile view on Thunderbird. Luckily that's a small portion of the market right now.

Outlook has also not grown as much as I'd hoped over the past decade. But clearly still takes the lead on the Desktop front.

Although the recent widespread Exchange server hacks gives reason for pause if you where the admin. But I digress.

Should I embed, link, attach that image?

Most notably embedding, attaching or linking images is supported by differently accross email clients with links being best supported and most hidden due to "privacy warnings".

KISS

Bottom line. When it comes to email design you can go to the moon and back if you've got the budget. Otherwise keeping to highly supported simpler layouts will come back in budget every time.

This reminds me of a good project principle.

Cheap, Good, Fast. Pick two.

Some neat posibillities

I do still create some pretty neat things these days in email though, like including sliders and menus and faq sections in mail. And buttons that work right out the gate. So it's not all lost.

However my most favorite email feature is still conscise writing and good formatting. Without this foundation it's pretty hard to build a good mail.

This is hardly surprising since so many users browse the web from their phones.

Recent case study

On a recent e-Commerce project the statistic was close to 90% of visitors.

Conversion still a challenge

Obviously this is hard to ignore although conversion on mobile is an interesting thing to consider with such limited screen space.

And the fact that mobile only users are often only slightly Digitally literate.

All people muddle their way through the web but when it comes to Mobile users they are the ultimate muddlers from my observation.

Conclusion

So as of 2021 if you're site performs poorly on mobile it will start affecting your rankings negatively.

It's clearly time to rethink & rework out Apps and Sites. While we at it a good dose of UX wouldn't hurt SEO or users either.

Just my two cents...

I've always liked the concise syntax to VueJs over ReactJs so I decided to give the two a go together.

Some early previews of the app working with working API intergration.

Ionic Vue comes with TS

So with VueJS and Ionic came a recommendation to keep Typescript. And so my journey began Mid Jan 2021 with types.

It's not been all love at first bite but after delving into a 60min crash course I've been able to survive the first few days. The promised gains seem worth the pain.

My first few days have come with intense pain though. After coding for a few days I kept running into Type errors that I did not quite know how to solve.

Initially it seemed that TS is the roadblock to getting any code to work. I'd write out perfect JS and it would fall on it's face every time. Test it outside of TS and it works flawlessly.

And after spending a few days chasing Type errors I decided to dig deeper as there has to be something I missed initially.

A few lessons learned

Run-time errors with TS and Ionic sometimes show skewed line numbers.

This seems to be a current bug relating to SFC in VueJS. My Temporary work around has been to code with hot reload and fix errors immediately before proceeding. It's a better way of coding that leads to better productivity any way.

Git is your friend

When line numbers go fuzzy and minutes go by. It's often easier to revert a small change and start it again. Since we've got git might as well put it to good use.

Types are easy

The fundamentals of Types are not hard. But you need to give you brain some time to absorb the implications in code.

Most of TS is really just JS and you can actually partially implement TS in a project.

Essentially Types are a way of documenting expected data types and values for

• variables
• arrays
• objects.

There's much debate around this but the simplest way is that you should only use Interfaces for Objects. For all the rest use type definitions.

Bypass Types in a pinch

In a pinch you can define the type as Any. But this should be used with caution as it sort of negates the benefits of using TS in the first place.

Sage Advice

As a Senior Ionic Dev pointed out types are mostly inferred in Ionic and you'll run into type issues if you're trying to do something too radical.

Wrap it up

Looking forward to seeing how TS will improve my development experience. I already enjoy the variable hinting TS introduces in VS Code.

So Here goes....

Github, Meet Jekyl

To get a Github pages site up you need to start a repo with your username.githubpages.com. You'll find the the getting started with github pages .

Can you say Jekyll?

This site is based of Jekyll which is a Jamstack site framework built with Ruby on Rails. It's Github's recommended default although you can use things like Hugo or others. I like the simplicity of Jekyll which allows for maximum design expression with little fuss.

Jekyll speaks HTML, Markdown, JSON and more. It's a fantastic way to get technical content up if you don't need a back-end.

Where do I put images in Jekyll

Under the main Assets folder. The _site folder is generated on build in Jekyll.

Adding classes in Jekyll Markdown

Just add your classes like this

{: .rounded .image}

![alt text](logo.png "Title")

This will render out the image tag with the classes you specified.

Ready Set Launch

Write, Build, Git Push and we're off to a beautiful friendship.

In 2020 I've built out a small Project in Laravel that handles Reseller packages and Pricing for B2B. It feels familiar coming from the Javascript side of things. I also discovered that Laravel combines ideas from JS and Ruby.

One of the Developers I follow online mentioned what they've been doing on Ruby and I was intrigued to take a look. Well I spent a today and learned the basics.

So far I like that Ruby is similar in it's ability to scaffold various parts of an application. After learning how that works it no longer seems like a Ruby Project can spin out of control.

What I like

• I like how easy CRUD is with Ruby - feels like Laravel.
• The stack feels less fragmented than JS stacks do.
• The language so far seems enjoyable.

What I may have to learn to love

• Deployment of Ruby projects seem to be a bit more complicated than PHP but not so much more complicated than Node.js apps. I manage several VPS' running production code. So It's not insurmountable to deploy.

What I learned

• Intalling a Ruby Development environment Learned that this part of Ruby on Windows can be tricky and how to get it done.
• Ruby MVC and Project structure The Ruby project Structure is remarkably easy to understand coming from Laravel
• Routing with Ruby Routing uses
• Variables in Ruby Ruby variables are just words like in Bash unless you want to increase their scope. Variables passed from controller to page are written @variable
• Finding and Using Gems
• Defining production vs development gems
• Controllers in Ruby Controllers are
• Migrations and Databases in Ruby
• Production v.s. Development configs
• Creating CRUD forms in Ruby
• Add custom styling to Ruby elements
• Use Devise to create login and profile pages
• Database Associations
• Controllers beyond basic Crud
• Deploying Ruby code to git and Heroku

Wrap up

Getting my feet wet with Ruby has been a good experience that has broadened my thinking. I love how simple the syntax is. And I'm looking forward to use some of the insights gained in other languages.

I may just build out a next personal project in Ruby for fun.

Our Goal

Build a [template engine]{https://github.com/barcovanrhijn/sitebuilder} and Cms that work together through an Api connection.

The idea was building template engine that could be easily filled out with details to generate brand sites.

Creating a Design System

I asked to do the front-end generating code. I was inspired by how Atomic Design systems worked and decided to build out a template engine with some overlapping features with Twigg.

Since the requirements was that there be no dependencies I could not use Twigg or Handlebars or other such systems.

The project consisted of three parts.

1. A UI that was customer facing and centrally manages all the site information and links (similar to a CMS backend).
2. Template builder which connects to the API and parses the Json into arrays and then outputs this in a template.
3. The API defines several settings that makes the Customer facing builder allow simple UI configurations and style changes.

I discovered that some of what I wanted to do to make the template more flexible is known as Meta programming. I discussed ways we could free the data model by moving to JsON in MySQL or MongoDB. Because after the first few days it became apparent that each new change in the data model introduced heaps of new work on both ends.

Moving the data model into JSON would actually allow dynamic assignment of some properties like classes. And would make implementing new classes and design features fairly easy. Allowing us to focus on getting to optimal designs for the front-end and back in a quicker time-frame.

It became clear that we needed a single language between the two code bases. I was starting to see a lot of variable assignment where I would reference a property on the API and rename it entirely.

So I came up with some naming conventions for different UI parts along with their properties. After we agreed on naming that made sense to both of us I documented this on a Wiki I'd started for our project. This in turn helped standardise the language in code and made it flow like good poetry.

I've always loved the simplicity of DokuWiki for such use cases.

I also started to get the sense that some of the design should be driven from the front end as it would allow more page flexibility for the template.

To fully enable this would require a more unlimited data model especially when it comes to how many rows and columns are involved in the final design.

Meeting PHP Unit

In the process of doing the work I decided to learn how to build unit tests in PHP.

I've just touched on the basics of doing this in Javascript after what I'd learned in FreeCodeCamp. But I'd not used this in PHP yet.

In the past I'd mostly customized PHP code or written small Wordpress plugins which did not have enough code to make Unit tests a viable option.

When I asked the developer I worked with it turned out that he had not used PHPUnit before,so I was on my own with this.

Lessons learned

• The project contributed valuable experience but the partnership was not well-matched.
• When comparing notes I was producing 6 Months of output in 3 Weeks compared to the other dev's output.
• I was putting out more hours and my workflow was more productive.
• The structure of our agreement was a percentage based project partnership which does not support varying degrees of input very well.
• I was teaching Git and local PHP setup techniques since he was still pushing changes through shared hosting web interface to view changes to the code base making collaboration painfully slow.
• Cooperation could have worked but the nature of the partnership agreement did not account how much each person puts in.

For future projects I'd favor an hourly fee or fixed monthly fee.

Wrap up

In 3 Weeks I coded up my Vanilla PHP and produced a minimum viable product as part of an attempt to partner up with this PHP developer.

I had started with a blank canvas and PHP documentation and 5min worth of Sage advice on how we'd structure the app.

All in all the project could be refined a lot, but I'm pretty pleased with the outcome given how short the development time-frame was.

We set out to create a template and fill it out with a loop.

I chose Python3 for the task. There are lots of libraries like Image Magic that have overlay systems. But this is done in Raster so the image will get re-compressed.

Then it hit me that SVG is really just an XML spec. And a great idea emerged.

• Add template tags like {{ name }} in a text box in an SVG file.
• Do a plain find and replace on the file.
• Convert to PNG with ChairoSVG

Wrap up

I ended up with a script that reads a template file and inserts fields from an Excel sheet. This can be extended further to run from within a PHP front end. But it works nicely as is.

I've got access to the backend but there's no API so making the data useful in a customer context requires some hacking.

I ended up going with the Python Requests library and used Xpath

# create sesson
session_requests = requests.session()
# extract CSRF token using xpath and lxml
login_url = "https://example.com/login.php"
result = session_requests.get(login_url)
tree = html.fromstring(result.text)
authenticity_token = list(
set(tree.xpath("//input[@name='loginSubmit']/@value")))[0]

# login & send payload
result = session_requests.post(
login_url,
data=payload,
headers=dict(referer=login_url)
)

Lessons learned

Load all the assets

• Interestingly it's important that you load all the assets (css and js) from the page to keep the scraper looking like a normal web client. Call it stealthy if you like.

• Useful for legacy integration. Scraping if not used maliciously can actually save lots of integration time. When dealing with legacy systems managed by 3rd parties it's an indispensable technique.

• Consider the resource you're scraping Always consider if the 3rd party is ok with you doing this. In my case I have permission to use the information.

• Remember the CSRF token CSRF tokens are a security measure to protect against bots. We're writing a scraping bot. But thankfully simpler forms are easy to submit - just include the CSRF token in the request after you identify and scrape it.

-Chasing a moving target Sites that change structure frequently are harder to scrape consistently. There will always be times when scraping breaks and needs re-adjustment.

Next Challenge

Scraping JS table data.

I know much of this will be a review, but I've seen how learning, then sharing deepens knowledge.

So after first helping an intern with Front End design back in 2017 I've opened up a lot things I'd like to explore in Front End design. So I'm eager to jump in and get started.

So it finally happened this week. After Dabbling in Linux from 2008 I started running hosting servers and managing Linux servers for clients in 2013. But now in 2018 I finally found a very compelling reason to only work from Linux rather than dual boot.

Some background

I started out my Career in the early 2000's in a small Software Development startup called P37 Solutions.

VB6 Meets Travel Agencies

The company built out software predominantly in Visual Basic 6 and later C# for the Travel Industry to simplify bookings through Amadeus a travel network.

Amadeus was known to introduce a slew of virus infections into Travel agencies and general machines used to be air-gaped from the Amadeus machines.

The Virus Coliseum

A Tech back then told me that once a machine hit around 2000-3000 virus infections it actually got more usable because the different viruses where competing for the same resources to the point that none of them had much success. These machines where so Virus Infected that you'd crash Windows by even attempting to clear anything up. I tried as a rookie, it was a pointless endeavour.

Anything was possible

P37 built out Smaller projects like stock management systems.

It was an interesting time in tech.

• XML was just becoming a standard that would lead to PDF and HTML standards among others.
• CSS1 was in its infancy, we had our first graduate Designer joining at the time.
• Linux had not been thought up yet. And our Dev house had been toying with writing an OS.

Volunteering

As a volunteer Part of my initial responsibilities in the Office was supporting Senior developers by rebuilding their the Windows 2000 and later XP machines.

Back then Dev machines would generally only remain reliable for 3-9months.

Developers where pushing these machines very hard and before XP. Testing Desktop software meant constantly adding DLL's and registry entries when installing and removing apps created heaps of clutter resulting in early Windows crashes.

Fast Forward 3 months

I quickly got hired 3months later and promoted to building out UI, Debugging and supporting customers (remotely as soon as the first cellular networks landed).

The firm hired a replacement to take care of hardware & OS maintenance while I stepped into a software & support role.

In a few months I Administrated the Windows Servers that ran production code we built.

Back to the Dev Stack

Back then the benchmark I set for rebuilding a Developer machine from Format to deployed was around 4hours.

This included all the tooling and custom components etc. that devs needed.

While it may sound long, most things where a manual process and this time cut the previous timeline by half. Deployment tooling & OS automation have come a long way since then. Many installers did not have terminal extensions.

Plug and Play was jokingly referred to as Plug and Pray in the pre Windows7 world.

We're really spoiled in the modern OS by loads of automations we take for granted.

So why I switched to Linux

Windows 8.1 the new Vista?

With the introduction of Windows 8 looking much like the historic release of Windows Millennium, I was eager to see what 8.1 would bring.

But sadly 8.1 looked like another Vista release taking effectively double the Ram to boot up that Windows 8 did.

It was not a great situation since you need every ounce of Ram once you start emulating Android devices, or LAMP Servers for WebDevelopment.

Back to Windows 7

I moved back to Windows7 it's a nice stable environment that works reliably for several years unless you really maintain it poorly and mess it up.

Trying out Development on Ubuntu

I'd been dual booting Ubuntu for a while and found it a wonderful space for Web Development. I moved some of my Front End development to Ubuntu 18.04. it was going great!

Upgrading to Windows 10

Windows 10 rolled around. It was more polished and reminded me of the early days of Windows7. At least it showed potential after it had been around a few months.

But it had one nagging issue. Forced updates was a mistake from the get go. Non-enterprise users where forced to become gineu pigs.

Microsoft had been culling its testing team for some years which has really reduced code quality.

The ultimate update wipes my drive

Anyway fast-forward to Oct 2018.

KB4532693 rolled around, and I was one of the lucky ones to get my drive wiped. But this update in my case low level formatted the drive beyond repair and dropped all partitions including Ubuntu with it Kamakazi style.

Windows7 crashes weeks after install

I moved back to Windows7 and somehow that installation was short-lived. It's a first experience after decades with Windows installations where I'd seen a double whammy.

Ubuntu - the start of a beautiful friendship

So this was the start of a beautiful friendship between me and my Ubuntu environment.

• It's fast and efficient.
• Updates are small.
• Redeploying after the crash is a dream.

I'm up and running from backups with my Bitbucket repo's synchronized and entire development stack reinstalled in about 90min flat.

And on top of that almost everything a Web Developer could ever want is native.

It has generally felt like learning to push such code to a Git repo would take more effort than reward. But after I’ve looked at other version control systems out there like SVN I decided that Git is a clear winner in terms of enabling team work. Team work was the bit that really got me interested in Git in the end.

the Intern

Recently had a Grad Student make contact for Internship. He’s a friend of a friend which made for a nice warm introduction. He’s about to finish his degree but has gotten stuck in the Job readiness department.

I’ve been looking at ways for us to collaborate remotely when we can’t work in person.

I ended up going with

• Asana
• Bitbucket
• Slack as our remote work stack. And we’ve just heading into a new project together.

We’ve taken quite some time going over Wordpress themes and setup for Web design.

Also moved my Development environment over to Ubuntu from Windows7 after dabbling in Windows8 then 8.1 then 10.

After careful consideration I actually enjoy using Bitbucket it’s got more functionality and is more integrated with Atlassian’s Development tool-set.

It’s been fairly easy to onboard an Intern. All it took was writing some walk-throughs and links to relevant docs and we’re all set. Shared this on our Wiki, and everyone was on the same page quickly.

Will be re-looking Github again in the future.

Some of the smaller projects like themes for Wordpress sites of small Businesses don’t really have the budget to invest in design systems.

I think as time goes on more businesses will start to think this way. But right now Small business is stuck in the design, neglect, abandon and redesign cycle. This really alienates end users who really resent having to re-learn how to use a site they love.

My take-away from this is moving consistently and incrementally in a design. And thinking in layers

And I'm looking forward to taking on larger projects that have room for the gains caused by getting everything consistent.

If you've not come across Brad Frost's Atomic Design you should really read it! It's a wonderful way to think of design as components.

I bounced the idea off a smaller client, but her level of alarm was enough to make me decide not to cause any customers undue panic. Interestingly I was able to turn this around and the customer never left. So I set off and moved 1000km away from most customers I worked with.

Initially it was hard work to keep up communications in ways that compensated for my lack of presence. Lots of phone calls and emails followed to keep project communications going. It became clear that the traditional tooling used when you have Face to Face contact is not really sufficient in remote interactions.

Strong trust relationships built with customers prior to the move made this a lot easier. I scheduled visits once in 6months to larger projects to just re-enforce the human connection. But as time moved on I was able to move to yearly visits.

Oddly looking back after two years most customers never knew that I left.

The only piece of the puzzle I have yet to solve at this time has been how to convey the same warmth in the sales phase as an in person connection. On-boarding new remote customers has been a bit more tricky in practice.

We live and learn, I think there's room for improving our processes. But it's clear that many parts of work are ready to go remote.