Once they’re out of design school and battling it out in the real world, designers can find themselves in a pretty crappy predicament.
Maybe your teachers warned you to be as discerning as possible when taking on new clients (or maybe they told you the opposite, but you knew it was BS), but reality is often a rude awakening from what you expected when you first started working.
Bills pile up, the rent’s due date looms closer, and suddenly that shady dude who wants you to design his logo and website for $200 and “exposure” doesn’t look too bad.
We all know it can be hard to stick to our guns and seek out quality work that will enhance our careers, rather than drag them down into the mud, but think about one thing for a second.
When you take on a terrible client – one that, say, refuses to pay you either in full or in part, or one that has a million and one changes to make to your designs, you’re actually spending far more in labor costs – and sometimes even in legal fees – to complete that job than you would have if you’d had a few more instant meals and committed to finding a good client.
A bad client is bad news, period. It will always cost you more to maintain a bad client than it’s worth.
Avoiding Micromanager
Clients hire you for a reason: to improve the profitability of their business venture, whether it’s an information website, a product, or a personal brand. At least initially, they know they need a professional to step in and create something usable and which contributes to their overall goal of making more money.
I’ve found that reminding clients of this in a polite, but firm way is incredibly effective in getting them to slow down and hand you back the reins of the project.
Your ultimate goal as a designer is to find clients who will trust you. If there’s no trust there, your clients may become overwhelmed with anxiety and begin to micromanage.
Generally speaking (but not always), the higher you price your design services, the more frequently you’ll find clients who respect your judgment and who will trust you, and the more you’ll drive away those who only want to play dictator.
Make sure you always charge what you’re worth – if you compromise on your prices at any point in your career, it becomes exponentially harder to make up the difference later on.
See No Evil
Nowadays, more and more designers work remotely rather than in person, and many may never even meet their clients face to face. This is good and bad. If you get a good client, it’s awesome to just receive the design brief, communicate through email, and work your magic.
If your client is a bit more difficult, it can be a nightmare. There’s a ton of research that points to face-to-face interaction and body language as being two of the most important factors in building a relationship of any kind – particularly one that involves business.
If you’re working virtually, there’s no way to gauge the chemistry between yourself and your potential client. This is where Zoom can be an immense help, but if you can meet in person, that’s even better.
Regardless of whether you do it in person or on the computer, for long-term projects, it’s important to see your client’s face and hear from their own lips whether or not their personality is something you can deal with.
You can learn a lot about what kind of client someone will be from the way they speak to you, the words they use to describe their work, and the nature of the work they would like you to do, and even from the state of their desk or office.
If someone is a slob, that might be a red flag. But more importantly, if you get a bad feeling from a client, take that as a cue to get the heck out of dodge.
The Warning Signs
If your client doesn’t respect what you do, they will let you know in subtle (and sometimes not-so-subtle) ways, particularly in the way they discuss the project they have for you.
The most obvious red flags are clients who promise you “exposure” or “more clients” at some indeterminate point in the future. If you’ve been hanging around the online design community for any length of time, you’ll know that doing spec work is one of the most detrimental things you can do for your own career, and for the design industry in general.
But even paying clients will use this one when they know they’re offering you payment that a service provider in any other industry would consider an insult. You don’t want to work for “exposure.” Yes, it’s a nice thing to have, but potential clients who say this never mean it the same way you mean it.
For you, exposure is concrete referrals. If your client can provide you with a list of actual paying clients you can contact for future paying work, then that’s fantastic; “expose” away. But if they don’t do this, that means they’re trying to game you and getting payment from them will likely be more trouble than it’s worth. Run!
The next big warning sign is potential clients who downplay the amount of time, effort, or work involved in a project.
“Oh, it shouldn’t really take you that long,” or “a student could do this,” or my favorite: “it’s just a simple little thing – I’d do it myself, but I don’t really have the time.” (By the way, if they don’t have the time to do a “simple little thing,” what makes them so sure it’ll only take you five minutes?)
A client who automatically assumes that what you do won’t take any significant amount of time is a client who does not understand what’s involved in the design process.
This is a client you want to run from, and quickly. Why? Because these are the kind of clients who will always argue with you about your rates or fees, since they’re convinced you’ve been racking up extra hours just to cheat them.
Of course you should be making your clients sign contracts to prevent any legal fiascos, but why put up with the headache when you don’t have to? Just walk away.
The last and possibly most insidious of “red flag” clients is the “designer” or “art director” client. You know the kind. The divorce lawyer or communications startup CEO who secretly wishes they had gone to design school, and who actively wants to play a part in the design process despite having no knowledge of design whatsoever.
These types of clients are also known for being impossible for most sane designers to work with. Therefore they often have unfinished design work that they want to hire you to complete.
They might call you at 3AM with “urgent” changes or ideas they’ve had about your work, or they might be wishy-washy about what they actually want you to do or what they like.
Long before a problem ever arises, you can use these straightforward steps to ensure that you don’t get caught up in a nasty whirlwind of broken contracts and legal fees. Always keep in mind that when you meet with a first-time client, you are evaluating them as much as they’re evaluating you.
The right clients will always respect your time and expertise; they will respond to your questions or concerns in a timely manner, and they will be realistic and professional in their expectations.
The post The Types of Freelance Design Clients You Should Avoid appeared first on Speckyboy Design Magazine.
Latest PECL Releases:
- uopz 6.1.2
- make UOPZ compatible with Xdebug again (2.9.4+ required)
- redis 5.3.0RC2
phpredis 5.3.0RC2
This release contains initial support for Redis 6 ACLs, LZ4 compression,
and many more fixes and improvements.
You can find a detailed list of changes in Changelog.md and package.xml
A special thanks to BlueHost for sponsoring ACL support o/
- Sponsors
~ Audiomack - https://audiomack.com
~ BlueHost - https://bluehost.com
~ Redis Cache Pro for WordPress - https://wprediscache.com
~ Avtandil Kikabidze - https://github.com/akalongman
phpredis 5.3.0RC2
- Fix LZ4 configuration and use pkg-config if we have it [df398cb0]
(Remi Collet)
- Make sure persistent pool ID is NULL terminated [0838b5bd, 57bb95bf]
(Michael Grunder)
- Run LZ4 tests in Travis [3ba3f06d] (Michael Grunder)
phpredis 5.3.0RC1
- Support for Redis 6 ACLs [a311cc4e] (Michael Grunder)
- LZ4 Compression [04def9fb] (Ilia Alshanetsky)
- Support for new Redis 6 arguments (XINFO FULL, SET KEEPTTL) [a0c53e0b,
f9c7bb57] (Michael Grunder, Victor Kislov)
- Support for TLS connections [890ee0e6, b0671296] (Pavlo Yatsukhnenko)
- New option Redis::SCAN_PREFIX, Redis::SCAN_NOPREFIX [e80600e2] (Pavlo
Yatsukhnenko)
- Configurable unit test authentication arguments [e37f38a3, 201a9759]
(Pavlo Yatsukhnenko, Michael Grunder)
- Improved cluster slot caching mechanism to fix a couple of bugs and make
it more efficient. [5ca4141c] (Michael Grunder)
- Stop calling Redis constructor when creating a RedisArray [e41e19a8]
(Pavlo Yatsukhnenko)
- Use ZEND_LONG_FMT instead of system
long [5bf88124] (Michael Grunder)
- Use long for SCAN iteration to fix potential overflow [f13f9b7c]
(Victor Kislov)
- Fix config.m4 to test for the variable $PHP_REDIS_JSON and not the
literal PHP_REDIS_JSON [20a3dc72] (Mizuki Nakano)
- Fix compiler warnings [b9b383f4, 215828e] (Remi Collet),
Pavlo Yatsukhnenko)
- Avoid use-after-free of RediSock [8c45816d] (Pavlo Yatsukhnenko)
- Fixed ZADD arginfo [a8e2b021] (Pavlo Yatsukhnenko)
- Store AUTH information in flags RedisSock rather than duplicating
information. [58dab564] (Pavlo Yatsukhnenko)
- Refactor redis_sock_get_connection_pool logic. [73212e1]
(Pavlo Yatsukhnenko)
- Updated documentation to show LPUSH and RPUSH are variadic and fixed DEL
documentation. [92f8dde1] (Michael Grunder)
- Authenticate in redis_server_sock_open [4ef465b5] (Pavlo Yatsukhnenko)
- Dynamically include json.so in unit tests based on configuration
[0ce7ca2f] (Michael Grunder)
- Update save_path logic in Redis Cluster session unit tests [dd66fce]
(Pavlo Yatsukhnenko)
- Refactoring various bits of logic [bbcf32a3, a42cf189, 460c8f29,
b7f9df75] (Pavlo Yatsukhnenko)
- Use the portable
ZEND_LONG_FORMAT family instead of C format specifiers
[b9b383f4](Remi Collet)
- PHP 8 compatibility [9ee94ca4, 7e4c7b3e] (Pavlo Yatsukhnenko)
- Refactor PHPREDIS_GET_OBJECT macro [d5dadaf6, 190c0d34]
(Pavlo Yatsukhnenko)
- Fix documentation showing lPush and rPush are variadic [6808cd6a]
(Michael Grunder)
- redis 5.3.0RC1
phpredis 5.3.0RC1
This release adds the first round of support for Redis 6 functionality including,
most importantly ACLs. Other Redis 6 functionality is included as well such as
KEEPTTL and XINFO FULL command support.
Aside from the Redis 6 functionality this releasae contains many bugfixes and
improvements.
- Sponsors
~ Audiomack.com - https://audiomack.com
~ BlueHost.com - https://bluehost.com
~ Redis Cache Pro for WordPress - https://wprediscache.com/
~ Avtandil Kikabidze - https://github.com/akalongman
- Support for Redis 6 ACLs [a311cc4e] (Michael Grunder)
- LZ4 Compression [04def9fb] (Ilia Alshanetsky)
- Support for new Redis 6 arguments (XINFO FULL, SET KEEPTTL) [a0c53e0b,
f9c7bb57] (Michael Grunder, Victor Kislov)
- Support for TLS connections [890ee0e6, b0671296] (Pavlo Yatsukhnenko)
- New option Redis::SCAN_PREFIX, Redis::SCAN_NOPREFIX [e80600e2] (Pavlo
Yatsukhnenko)
- Configurable unit test authentication arguments [e37f38a3, 201a9759]
(Pavlo Yatsukhnenko, Michael Grunder)
- Improved cluster slot caching mechanism to fix a couple of bugs and make
it more efficient. [5ca4141c] (Michael Grunder)
- Stop calling Redis constructor when creating a RedisArray [e41e19a8]
(Pavlo Yatsukhnenko)
- Use ZEND_LONG_FMT instead of system
long [5bf88124] (Michael Grunder)
- Use long for SCAN iteration to fix potential overflow [f13f9b7c]
(Victor Kislov)
- Fix config.m4 to test for the variable $PHP_REDIS_JSON and not the
literal PHP_REDIS_JSON [20a3dc72] (Mizuki Nakano)
- Fix compiler warnings [b9b383f4, 215828e] (Remi Collet),
Pavlo Yatsukhnenko)
- Avoid use-after-free of RediSock [8c45816d] (Pavlo Yatsukhnenko)
- Fixed ZADD arginfo [a8e2b021] (Pavlo Yatsukhnenko)
- Store AUTH information in flags RedisSock rather than duplicating
information. [58dab564] (Pavlo Yatsukhnenko)
- Refactor redis_sock_get_connection_pool logic. [73212e1]
(Pavlo Yatsukhnenko)
- Updated documentation to show LPUSH and RPUSH are variadic and fixed DEL
documentation. [92f8dde1] (Michael Grunder)
- Authenticate in redis_server_sock_open [4ef465b5] (Pavlo Yatsukhnenko)
- Dynamically include json.so in unit tests based on configuration
[0ce7ca2f] (Michael Grunder)
- Update save_path logic in Redis Cluster session unit tests [dd66fce]
(Pavlo Yatsukhnenko)
- Refactoring various bits of logic [bbcf32a3, a42cf189, 460c8f29,
b7f9df75] (Pavlo Yatsukhnenko)
- Use the portable
ZEND_LONG_FORMAT family instead of C format specifiers
[b9b383f4](Remi Collet)
- PHP 8 compatibility [9ee94ca4, 7e4c7b3e] (Pavlo Yatsukhnenko)
- Refactor PHPREDIS_GET_OBJECT macro [d5dadaf6, 190c0d34]
(Pavlo Yatsukhnenko)
- Fix documentation showing lPush and rPush are variadic [6808cd6a]
(Michael Grunder)
The post Interview with Nils Adermann and Jordi Boggiano appeared first on Voices of the ElePHPant.
As the web has evolved over time, website complexity has trended upward. Why? Technology has allowed us to do more than ever.
Between content management systems (CMS), code frameworks and other technological advancements, high-end functionality is at our fingertips. This has raised the bar in not only what we can achieve, but what our clients expect of us as well.
While this evolution has brought a lot of positives, it has also made website maintenance all the more difficult. It’s the result of so many disparate pieces being brought together. In some ways, it’s also the price of taking advantage of the latest and greatest techniques.
With that, let’s take a look at (in no particular order) five of the more painful maintenance-related issues that many modern websites face.
The Web Designer Toolbox
Unlimited Downloads: 1,000,000+ Web Templates, Themes, Plugins, Design Assets, and much more!
Ever-Changing APIs
A lot of websites depend on third-party APIs these days. They enable us to connect with providers such as Google Maps, Mailchimp and virtually every social media network out there.
Each API is different and, as you might expect, have their own unique quirks. And they also release new versions that one might view as a double-edged sword.
On one hand, it’s great to see a particular API evolve and add new features. There is a downside, though. Sometimes these changes require us to update our own implementations. Failure to do so can lead to a broken feature.
As an example, several years ago Twitter made an API change that resulted in a lot of issues for third-party providers. More recently, Instagram’s updated API meant users had to reauthenticate their apps in order to display feeds on their website.
It can be a major pain to keep up with all of these changes for even one website. If you manage multiple websites that use various APIs, you may not find out about a change until it’s too late.
Abandoned or Poorly-Maintained Plugins
A healthy variety of plugins is part of what makes an open-source CMS thrive. If developers are out there creating new functionality for a platform such as WordPress, it becomes more attractive to new users.
But variety itself does not guarantee quality or even a lengthy existence. Because anyone can publish a plugin, that means living with a lot of uncertainty. As platforms evolve, a particular plugin may not come along for the ride.
For web designers and their clients, this results in occasionally having to reinvent the wheel a bit. If a plugin we’ve chosen is buggy, no longer maintained by its author or both, a replacement must be found.
The more complex the plugin, the more painful it is to replace. It’s not just finding a new plugin, however. Any customizations made around the previous one will have to be refactored.
The whole process could become expensive and time-consuming.
Web Hosting Nightmares
We depend so much on web hosts. How much? Think of it this way: no matter how well-built a website is, it can’t overcome substandard hosting.
And, when hosts don’t hold up their end of the bargain, things can quickly become a nightmare. Frequent outages, security holes or lackluster support make our jobs that much harder. Especially so, considering that web designers are often caught in the middle.
We’re the ones who are typically the go-between for our client and the hosting provider. It could mean lots of time waiting in a chat or (even worse) hanging on the phone for answers.
Meanwhile, the website in question may or may not be available. Good times.
Dealing with Old Websites
The longer you’re in this industry, the more potential you have for “old” projects to still be floating around the interwebs. Quite often, it’s for a client who is on a budget or just doesn’t see the need for a redesign.
While an older site in itself isn’t a problem, the way it was built could be. Designers and developers often learn through experience. The techniques we used five years ago are likely miles away from how we’d do it today.
Thus, when one of these golden oldies needs maintenance, it can bring back every mistake we might have made on the project. It can make one kick themselves for not being able to predict the future.
On the bright side, digging through old code can make you better appreciate how far you’ve come.
The Mysteries of an Inherited Site
The oft-repeated “box of chocolates” reference from the film Forrest Gump could easily be applied to websites we inherit from other designers. You really have no idea what you’re dealing with until you examine every bit of code. And, even then, there can still be surprises.
What’s really fun is that an inherited site could leave you to work through every one of the items on this list. Abandoned plugins, outdated API calls, a poor hosting environment and other assorted issues could be lurking beneath the surface.
It takes a bit of bravery and a lot of patience to work on these types of projects. That’s why it’s important to charge accordingly for the challenge.
How Pain Can Lead to Growth
The above “pains” all have a few things in common. First, they are simply a part of our job – fun or not. While completely static websites still exist (and are making a comeback), there are still requirements for dealing with third-party apps and services. And no website is immune to hosting foibles.
In addition, each of these items provides an opportunity for web designers to learn and grow. The experiences we have can help us better understand how to deal with similar issues in the future.
That’s a good thing because the web’s complexities aren’t going away anytime soon.
The post The 5 Biggest Pains in Website Maintenance appeared first on Speckyboy Design Magazine.
Package:
Summary:
E-commerce system that supports discount coupons
Groups:
Author:
Description:
This package can implement an e-commerce system that supports discount coupons...
Read more at https://www.phpclasses.org/package/11703-PHP-E-commerce-system-that-supports-discount-coupons.html#2020-06-30-03:14:22
Package:
Summary:
Exchange messages with WeChat users
Groups:
Author:
Description:
This package can be used to exchange messages with WeChat users...
Read more at https://www.phpclasses.org/package/11702-PHP-Exchange-messages-with-WeChat-users.html#2020-06-29-17:43:13
Wow, quite a long time since I last wrote a blog post, which clearly hinted towards at least a part two one day. I recently started blogging elsewhere (more on that below) and kinda forgot about my old blog. Lately I have been getting spam on it though, which reminded me of this old post. So here comes part two. I should add that it didn?t really take me 5 years to mature my thoughts on this topic, it just ended up that I communicated those thoughts in other places.
That being said, one of the first learnings as I dove into this topic was that that step one was listening and learning. Basically I started expanding my twitter timeline to include more people specifically tweeting about the issues of diversity and inclusion. But also simply following more people with marginalized communities talking about tech.
I paid attention to the dynamics in discussions. But one of the most clear ways I finally realized and fully accepted that meritocracy is a myth came with this github study that showed that while acceptance rates of PRs from women were well below those of men, the acceptance rate of PRs from women that hid their gender even slightly outpaced those of men.
Due to this reality and the constant pins and needles on top of deliberate harassment, where keeping people from marginalized communities away and pushing those that made it out. We keep hearing about some pipeline problem but the real issue is that people from marginalized communities just see no point in staying. But obviously this is not the root cause. Just going from my personal experience at Liip, I can name more female developers that left IT than male, despite us having way more male developers. The good news here, better diversity is entirely possible in tech if we actually work hard on inclusion. This is why people say ?diversity means nothing without inclusion?.
So with those realizations, I came across a tweet in the spring of 2017 by Erin pointing out the issues with an all white men speaker line up for a SymfonyLive event in the US. I first started rattling off excuses (note sure if just in my head or also in tweets), but eventually this finally gave me the kick I needed to become active. So I started reading more blog posts on the topic. Thanks to Liip?s education budget for all its employees, I ended up hiring Sage Sharp to help me figure out the next steps Symfony should be taken and what pitfalls to avoid that could cause further harm.
I was very happy to find that the Symfony core team was very receptive to this topic. Later that year we formally launched the diversity initiative. More importantly the community, aside from a few voices, was supportive as well and willing to learn and welcome change. We focused on several topics, like improving the language in our docs and on the website. We worked on guides for how to give and receive feedback in issues and PRs but more importantly we also worked on making those a lived reality. Quickly contributors started approaching the diversity initiative for support when they encountered situations where they felt overwhelmed. This helped deescalate a lot of situations but also helped train many contributors.
We also implemented a diversity scholarship to allow people from marginalized communities, that could otherwise not attend, to come and join us at SymfonyCon. One of the biggest successes was the adoption of a code of conduct, which lays the groundwork for safety as we hope to grow our diversity. More importantly, we worked in defining reporting processes and get the CARE (Code of Conduct Active Response Ensurers) trained by Sage Sharp so that they are prepared properly to enforce the code of conduct and sure reporters are properly protected and supported. Overall from the feedback I have seen we have made significant strides in improving our communication and openness. You can read more about this on the Symfony blog.
That being said, all of this hasn?t fixed our demographic issues within the Symfony community. There are still only men on the core team. While there are more visible figures within the Symfony community with a diverse background, we are still miles away from even just reaching the demographic representation of the proprietary software world, let alone the world in general. This is a long long
Truncated by Planet PHP, read more at the original (another 2633 bytes)
Latest PEAR Releases:
