Either way, your relationship with your web developer can be difficult to manage. We’re developers, so we know that there are so, so many ways the relationship can fall apart:

• Missed deadlines
• Lack of communication
• Slow communication
• No communication
• Developer over-promises
• Developer under-delivers
• Developer disappears
• Loosely defined scope
• Lack of protocol for small assumptions/decisions
• Bugs or issues don’t get fixed

Practically every designer we work with has shared a horror story involving one of those things. In order to avoid becoming a horror story ourselves, we’ve developed a handy list of pre-kickoff discussion items to help us avoid these kinds of issues.

Before we get into it, let’s be clear: This is not a cure-all for all designer/developer relationships. At the end of the day, it’s still a human relationship—it’s complicated. But we’ve found that an open conversation about these items can start a project off on the right foot.

1. How Will We Communicate?

How will you communicate while working on the project? Slack? Phone calls? Texts? Emails? PM software? Just as importantly: How often will you communicate? Every day? Once a week? At kickoff, and then not again until QA? If you’re doing a daily check-in, will it be a two-sentence email, or a 15-minute phone call? What’s the plan in case of emergencies?

More communication does not always equal better communication

There are no wrong answers here, as long as you set expectations at beginning. But remember: More communication does not always equal better communication.

Why This Matters

You want to have a good rapport with your developer, and to accomplish that, you need an established mode of communication. Usually a phone call is helpful to develop an initial personal connection, and to make sure it’s a good personality fit.

During development, work to strike a balance between checking in too much and too little. Too much and you’re micro-managing. Too little and the developer might not stay on track. It’s best to set the expectations at the top and stick to them.

2. How Will You Manage the Project?

Where are the files and login credentials the developer will need? Where will you track tasks, milestones, and deadlines? What software will you use? Basecamp? Trello? Asana? A spreadsheet or Google Doc? Basically, define the central hub for everything related to the project.

Why This Matters

During the project, your project management and communication should be centralized and trackable. A lot of time can be lost in the back-and-forth of looking for files, check-ins, updates, progress, questions, decisions, etc.  That’s why it’s important to establish where the developer can find everything they need.

3. Who’s Calling the Shots?

Are you the final decision maker on the project? Is there a UI/UX team involved? Is there anyone else who has input on decisions? Is there a marketing team or a manager who wants to weigh in on decisions? Is anyone else other than you going to be giving direction directly to the developer? When does the client come in, and how many decisions does the client get to make? Will the client have direct communication with the developer?

Why This Matters

You don’t want to backpedal on development, or have your developer redo work. To avoid that, it’s important that every stakeholder is aware of all relevant decisions—and that each decision is recorded in a single, central location.

4. How Should the Developer Handle Assumptions and Small Decisions?

How much freedom does the developer have while interpreting designs? Should they build the website pixel-perfect according to the designs, or should they make small assumptions around consistency and reusability of sections? If you’ve designed a responsive site, have you designed for all breakpoints? Have you provided notes regarding animations, transitions, and hover effects? Have you designed validation states for fields? (i.e. the popups: “Password invalid.” or “Username doesn’t exist”.) If you haven’t, is the developer free to make decisions or suggestions?

Why This Matters

Very often, designers are dissatisfied when a website doesn’t closely match the designs—or conversely, when the site too closely follows the designs, to the detriment of its performance or the project’s timeline. At the beginning, define your intended level of detail. It makes for a much smoother QA process.

5. What is the timeline?

What’s the hard deadline for the project, and what’s the soft deadline? Is there a major press hit happening that the site needs to be launched for? If the deadline is ambitious, is there a way to launch it in phases? What’s the expectation for responding to quick changes? One week turnaround? Less than an hour?

Why This Matters

it really doesn’t help to create artificial hard deadlines…honesty is the best policy

If there’s a hard deadline, make the developer aware of it, and make sure to leave time for proper testing. After the site launches, know that most developers can’t be on call at all hours to make changes. Waiting for a developer to make a fix can be frustrating, but even small requests require maintaining version control, launching the development environment, connecting to the server, deploying to the production site, etc. Determine ahead of time how long you expect fixes and changes to take, and take stock of the priority level of each task.

Also, it really doesn’t help to create artificial hard deadlines. Just be transparent with your developer and trust them to deliver accordingly. Again, you’re building a relationship, here. Honesty is the best policy.  

6. What’s the Structure of the Scope, Contract, and Payment Structure?

What’s the project fee? What’s the benchmark for the end of the project? What is included in the scope of the project? When does payment go out? Are you hiring the developer to do the project at an hourly or fixed rate?

Why This Matters

The last thing you want is a developer getting a site 95% of the way there, and then not launching the project due to a discrepancy in the scope/contract/payment.

Conclusion

Overall, setting expectations and communication are the critical things here. It can feel a bit silly to discuss how you’re going to talk to each other during a project, especially if you already have a good rapport. But it’s always good to just set expectations ahead of time, so you don’t end up inside your own horror story.

Atyx Inc. is a Chicago based Web Development company focusing on WordPress and Web-related projects.

Be sure to check out some of our services: cPanel Management, Managed WordPress Solutions, Web Development Services

The post 6 Things to Discuss With Your Web Developer appeared first on Atyx Inc..

Well, then you’re not good at doing your job.

Design is about making an idea possible, it’s not about having an idea. In reality, your idea is the cheapest thing you own.

“Ideas aren’t worth that much on their own. Even the most brilliant idea is just a starting point, not something magical. A significantly compromised but executed design is infinitely more valuable than an abstract notion in mental isolation.” (Thought Merchants)

The other day I was reading a great article byA List Apart on the illusion of control in web design. The article talks about how we, as designers, try to scrutinize every detail of an interaction — from pixel-perfect designs, to beautiful animations, to each tiny fraction of a second of the user’s experience — but the harsh reality is that we control way less than we think.

“The high fidelity of today’s design tools creates the illusion that our mockups are feasible out in the real world.”

The high fidelity of today’s design tools creates the illusion that our mockups are feasible out in the real world. Designing a static board or even a Principle prototype is relatively easy. You’re usually illustrating an ideal flow. You’re not accommodating for multiple scenarios. You’re not concerned about performance. You’re not designing for edge cases, for less tech savvy users, for older devices.

“The moment a design starts to be built is the line that separates good from great designers.”

Good designers can come up with ideas, but they can’t handle hourly JIRA tickets coming from the developers, asking for solutions for scenarios the designer didn’t even think of in the first place. Great designers thrive in those situations, creating a collaborative environment where developers feel like they own the solution as much as they own the problem.

Good designers will then come up with quick fixes for those secondary use cases, and throw the ball over the fence to the developers. Great designers will take every request as an opportunity to re-evaluate, improve, and bulletproof the design system at large.

Good designers will finish the project and say that it’s a bummer that the implementation looks so different than what was designed. Great designers understand it’s not about “looking like the mockups”; it’s about looking and feeling simple, useful, smooth, and relevant.

When we hear people saying that they are not strong when it comes to executing, iterating, adapting, and making it work, we question how strong of a designer they actually are and how they can justify charging customers exorbitant pricing for sub-par designs. This is the driving factor for why we even started a Web Design and Development company in the first place.

That’s not to say concepting is easier than executing. Not at all. Two different tasks; two different parts of the brain. But if you’re only able to come up with high-level concepts, then you’re not delivering an actual user experience. You are delivering a dribbble shot, a portfolio mockup, a piece of art.

The post Design is about finishing projects – not great ideas. appeared first on Atyx Inc..

Meaningful preset values when autocompleting CSS functions

Some CSS properties, like filter, take functions for values. For example, filter: blur(1px) adds a 1-pixel blur to a node. When autocompleting properties like filter, DevTools now populates the property with a meaningful value so that you can preview what kind of change the value will have on the node.

Relevant Chromium issue: #931145

Clear site data from the Command Menu

Press Control+Shift+P or Command+Shift+P (Mac) to open the Command Menu and then run the Clear Site Datacommand to clear all data related to the page, including: Service workers, localStorage, sessionStorage,IndexedDB, Web SQL, Cookies, Cache, and Application Cache.

Clearing site data has been available from Application > Clear Storage for a while. The new feature in Chrome 75 is being able to run the command from the Command Menu.

If you don’t want to delete all site data, you can control what data gets deleted from Application > Clear Storage.

#942503

View all IndexedDB databases

Previously Application > IndexedDB only allowed you to inspect IndexedDB databases from the main origin. For example, if you had an <iframe> on your page, and that <iframe> was using IndexedDB, you wouldn’t be able to see its database(s). As of Chrome 75, DevTools shows IndexedDB databases for all origins.

Relevant Chromium issue: #943770

View a resource’s uncompressed size on hover

Suppose that you’re inspecting network activity. Your site uses text compression to reduce the transfer size of resources. You want to see how large the page’s resources are after the browser uncompresses them. Previously this information was only available when using large request rows. Now you can access this information by hovering over the Sizecolumn.

Relevant Chromium issue: #805429

Inline breakpoints in the breakpoint pane

Suppose that you add a line-of-code breakpoint to the following line of code:

document.querySelector('#dante').addEventListener('click', logWarning);

For a while now DevTools has enabled you to specify when exactly it should pause on a breakpoint like this: at the beginning of the line, before document.querySelector('#dante') is called, or before addEventListener('click', logWarning) is called. If you enable all 3, you’re essentially creating 3 breakpoints. Previously the Breakpoints pane did not give you the ability to manage these 3 breakpoints individually. As of Chrome 75 each inline breakpoint gets its own entry in the Breakpoints pane.

Relevant Chromium issue: #927961

IndexedDB and Cache resource counts

The IndexedDB and Cache panes now indicate the total number of resources in a database or cache.

Relevant Chromium issues: #941197, #930773, #930865

Setting for disabling the detailed inspect tooltip

Chrome 73 introduced detailed tooltips when in Inspect mode.

You can now disable these detailed tooltips from Settings > Preferences > Elements > Show Detailed Inspect Tooltip.

Relevant Chromium issue: #948417

Setting for toggling tab indentation in the Sources panel editor

Accessibility testing revealed that there was a tab trap in the Editor. Once a keyboard user tabbed into the Editor, they had no way to tab out of it because the Tab key was used for indentation. To override the default behavior and use Tab to move focus, enable Settings > Preferences > Sources > Enable Tab Moves Focus.

This article was originally uploaded to Developers.Google.com

Atyx Inc. is a Chicago based Web Development company focusing on WordPress and Web-related projects.

Be sure to check out some of our services: cPanel Management, Managed WordPress Solutions, Web Development Services

The post What’s new in Chrome 75 DevTools appeared first on Atyx Inc..

]]> https://atyxinc.com/blog/chatbots-are-simply-annoying/ Fri, 19 Apr 2019 16:35:48 +0000 https://atyxinc.com/?p=265 While it may feel cute to have your customers or yourself talk to a computer, chatbots provide little to no value to many business processes and functions. In our opinion, chatbots are simply annoying and ineffective, and we’ll tell you why you should steer clear. The question shouldn’t be if we can have a voice […]

The post Chatbots are simply annoying appeared first on Atyx Inc..

]]> While it may feel cute to have your customers or yourself talk to a computer, chatbots provide little to no value to many business processes and functions. In our opinion, chatbots are simply annoying and ineffective, and we’ll tell you why you should steer clear.

The question shouldn’t be if we can have a voice conversation with our applications, as we clearly can, but whether we should.

Natural language processing has been around for quite some time, however, only recently has it gotten practical, and yet, it’s still not perfect.

It seems very inefficient to resort to imprecise systems when we have more precise systems available at hand. A chatbot on a website is bound to impress some people while annoying others at the same time. There are definite use-cases for when a chatbot on a website may be ideal, however, your business most likely does not fall into that category.

You’re far better off implementing marketing lists that reward your loyal subscribers and customers with exclusive deals and offers. With marketing opt-in’s implemented on your website (with the help of Atyx’s Web Development or Managed WordPress Solutions), it’s a great idea to implement a ‘Contact Us’ page with a built in contact form users can utilize to send you questions and concerns. Implementing a chatbot on a website is usually equivalent to a Contact form except more annoying, and the users don’t really know that what they’re about to send to the chatbot is going to end up in your email or third-party application anyway.

People often forget that using your keyboard and mouse is still considered talking to your computer, regardless of whether it’s in a fully customized contact form that makes sense for your business or an annoying pop-up that users aren’t familiar with.

The post Chatbots are simply annoying appeared first on Atyx Inc..

]]>