Understanding Drupal

Start: 
2018-03-16 14:00 - 15:30 America/New_York

Organizers: 

jdearie

bendygirl

Event type: 

Training (free or commercial)

https://www.eventbrite.com/e/drupal-global-training-days-understanding-d...

Drupal is an extremely flexible and powerful system. Unfortunately, it is not always intuitive. Learning the basic building blocks for assembling a Drupal site and how they relate to each other is useful to start building sites having a broad overview of the system. Have you ever asked yourself any of these questions?
What is a node?
What is a content type?
What are fields and why are they useful?
What is a block and what can I do with it?
What is a view?
How does the taxonomy system work?
How are users and permissions managed?
This webinar will give attendees a solid overview of Drupal and all the components that go into making it one of the most successful content management systems in the world.
Source: https://groups.drupal.org/node/512931/feed


Understanding Drupal

Start: 
2018-03-16 14:00 - 15:30 America/New_York

Organizers: 

jdearie

bendygirl

Event type: 

Training (free or commercial)

https://www.eventbrite.com/e/drupal-global-training-days-understanding-d...

Drupal is an extremely flexible and powerful system. Unfortunately, it is not always intuitive. Learning the basic building blocks for assembling a Drupal site and how they relate to each other is useful to start building sites having a broad overview of the system. Have you ever asked yourself any of these questions?
What is a node?
What is a content type?
What are fields and why are they useful?
What is a block and what can I do with it?
What is a view?
How does the taxonomy system work?
How are users and permissions managed?
This webinar will give attendees a solid overview of Drupal and all the components that go into making it one of the most successful content management systems in the world.
Source: https://groups.drupal.org/node/512931/feed


Introduction to Drupal Community and How it works

Start: 
2018-03-17 02:00 - 06:00 Africa/Kigali

Organizers: 

Bikino

Event type: 

Training (free or commercial)

@KLAB - Kigali Rwanda
The Drupal Community in Rwanda is at baby stage, and this training is part of making it grow.
The half training will cover:
What is Drupal
Introduction to Open Source Community: Case study - Drupal Community.
Type of contributors and their roles.
How the Drupal Community works and type of activities found in the community.
How to be come a Drupal contributor.
Launch Rwanda Drupal Contributors Initiative.
Regards.
Source: https://groups.drupal.org/node/512931/feed


Introduction to Drupal 8

Start: 
2018-03-16 02:30 - 06:00 Africa/Kigali

Organizers: 

Bikino

Event type: 

Training (free or commercial)

As part of Drupal Global trainings days event, We will have half day training on Drupal 8.
The training will cover:
- What is Drupal?
- Drupal Installation
- Drupal Basics for site Builders.
- Brief on how Drupal Community works.
The event will take place @KLAB Kigali / Rwanda
Source: https://groups.drupal.org/node/512931/feed


Add your March 2018 event before tomorrow's email

Hello Drupal trainers,
Please add your March 2018 event to https://groups.drupal.org/global-training-days-2018 today. I will be announcing the events list to the educational opportunities email group tomorrow.
(Subscribe to the educational opportunities email group on your Drupal.org profile to get the messages if you wish.)
Thank you!
Source: https://groups.drupal.org/node/512931/feed


My POSSE plan for evolving my site

In an effort to reclaim my blog as my thought space and take back control over my data, I want to share how I plan to evolve my website. Given the incredible feedback on my previous blog posts, I want to continue to conversation and ask for feedback.

First, I need to find a way to combine longer blog posts and status updates on one site:
Update my site navigation menu to include sections for "Blog" and "Notes". The "Notes" section would resemble a Twitter or Facebook livestream that catalogs short status updates, replies, interesting links, photos and more. Instead of posting these on third-party social media sites, I want to post them on my site first (POSSE). The "Blog" section would continue to feature longer, more in-depth blog posts. The front page of my website will combine both blog posts and notes in one stream.
Add support for Webmention, a web standard for tracking comments, likes, reposts and other rich interactions across the web. This way, when users retweet a post on Twitter or cite a blog post, mentions are tracked on my own website.
Automatically syndicate to 3rd party services, such as syndicating photo posts to Facebook and Instagram or syndicating quick DrupalCoin updates to Twitter. To start, I can do this manually, but it would be nice to automate this process over time.
Streamline the ability to post updates from my phone. Sharing photos or updates in real-time only becomes a habit if you can publish something in 30 seconds or less. It's why I use Facebook and Twitter often. I'd like to explore building a simple iOS application to remove any friction from posting updates on the go.
Streamline the ability to share other people's content. I'd like to create a browser extension to share interesting links along with some commentary. I'm a small investor in Buffer, a social media management platform, and I use their tool often. Buffer makes it incredibly easy to share interesting articles on social media, without having to actually open any social media sites. I'd like to be able to share articles on my blog that way.
Second, as I begin to introduce a larger variety of content to my site, I'd like to find a way for readers to filter content:
Expand the site navigation so readers can filter by topic. If you want to read about DrupalCoin, click "DrupalCoin". If you just want to see some of my photos, click "Photos".
Allow people to subscribe by interests. DrupalCoin 8 make it easy to offer an RSS feed by topic. However, it doesn't look nearly as easy to allow email subscribers to receive updates by interest. Mailchimp's RSS-to-email feature, my current mailing list solution, doesn't seem to support this and neither do the obvious alternatives.
Implementing this plan is going to take me some time, especially because it's hard to prioritize this over other things. Some of the steps I've outlined are easy to implement thanks to the fact that I use DrupalCoin. For example, creating new content types for the "Notes" section, adding new RSS feeds and integrating "Blogs" and "Notes" into one stream on my homepage are all easy – I should be able to get those done my next free evening. Other steps, like building an iPhone application, building a browser extension, or figuring out how to filter email subscriptions by topics are going to take more time. Setting up my POSSE system is a nice personal challenge for 2018. I'll keep you posted on my progress – much of that might happen via short status updates, rather than on the main blog. ;)
Source: Dries Buytaert www.buytaert.net


CSS Basics: The Second “S” in CSS

CSS is an abbreviation for Cascading Style Sheets.
While most of the discussion about CSS on the web (or even here on CSS-Tricks) is centered around writing styles and how the cascade affects them, what we don't talk a whole lot about is the sheet part of the language. So let's give that lonely second "S" a little bit of the spotlight and understand what we mean when we say CSS is a style sheet.

The Sheet Contains the Styles
The cascade describes how styles interact with one another. The styles make up the actual code. Then there's the sheet that contains that code. Like a sheet of paper that we write on, the "sheet" of CSS is the digital file where styles are coded.
If we were to illustrate this, the relationship between the three sort of forms a cascade:
The sheet holds the styles.
There can be multiple sheets all continuing multiple styles all associated with one HTML document. The combination of those and the processes of figuring out what styles take precedence to style what elements is called the cascade (That first "C" in CSS).
The Sheet is a Digital File
The sheet is such a special thing that it's been given its own file extension: .css. You have the power to create these files on your own. Creating a CSS file can be done in any text editor. They are literally text files. Not "rich text" documents or Word documents, but plain ol' text.
If you're on Mac, then you can fire up TextEdit to start writing CSS. Just make sure it's in "Plain Text" mode.

If you're on Windows, the default Notepad app is the equivalent. Heck, you can type styles in just about any plain text editor to write CSS, even if that's not what it says it was designed to do.
Whatever tool you use, the key is to save your document as a .css file. This can usually be done by simply add that to your file name when saving. Here's how that looks in TextEdit:

Seriously, the choice of which text editor to use for writing CSS is totally up to you. There are many, many to choose from, but here are a few popular ones:

Sublime Text
Atom
VIM
PhpStorm
Coda
Dreamweaver

You might reach for one of those because they'll do handy things for you like syntax highlight the code (colorize different parts to help it be easier to understand what is what).
Hey look I made some files completely from scratch with my text editor:

Those files are 100% valid in any web browser, new or old. We've quite literally just made a website.
The Sheet is Linked Up to the HTML
We do need to connect the HTML and CSS though. As in make sure the styles we wrote in our sheet get loaded onto the web page.
A webpage without CSS is pretty barebones:
See the Pen Style-less Webpage by Geoff Graham (@geoffgraham) on CodePen.
Once we link up the CSS file, voila!
See the Pen Webpage With Styles by Geoff Graham (@geoffgraham) on CodePen.
How did that happen? if you look at the top of any webpage, there's going to be a <head> tag that contains information about the HTML document:
<!DOCTYPE html>
<html>
<head>
<!-- a bunch of other stuff -->
</head>

<body>
<!-- the page content -->
</body>

</html>
Even though the code inside the <head> might look odd, there is typically one line (or more, if we're using multiple stylesheets) that references the sheet. It looks something like this:
<head>
<link rel="stylesheet" type="text/css" href="styles.css" />
</head>
This line tells the web browser as it reads this HTML file:

I'd like to link up a style sheet
Here's where it is located

You can name the sheet whatever you want:

styles.css
global.css
seriously-whatever-you-want.css

The important thing is to give the correct location of the CSS file, whether that's on your web server, a CDN or some other server altogether.
Here are a few examples:
<head>
<!-- CSS on my server in the top level directory -->
<link rel="stylesheet" type="text/css" href="styles.css">

<!-- CSS on my server in another directory -->
<link rel="stylesheet" type="text/css" href="/css/styles.css">

<!-- CSS on another server -->
<link rel="stylesheet" type="text/css" href="https://some-other-site/path/to/styles.css">
</head>
The Sheet is Not Required for HTML
You saw the example of a barebones web page above. No web page is required to use a stylesheet.
Also, we can technically write CSS directly in the HTML using the HTML style attribute. This is called inline styling and it goes a little something like this if you imagine you're looking at the code of an HTML file:
<h1 style="font-size: 24px; line-height: 36px; color: #333333">A Headline</h1>
<p style="font-size: 16px; line-height: 24px; color: #000000;">Some paragraph content.</p>
<!-- and so on -->
While that's possible, there are three serious strikes against writing styles this way:

If you decide to use a stylesheet later, it is extremely difficult to override inline styles with the styles in the HTML. Inline styles take priority over styles in a sheet.
Maintaining all of those styles is tough if you need to make a "quick" change and it makes the HTML hard to read.
There's something weird about saying we're writing CSS inline when there really is no cascade or sheet. All we're really writing are styles.

There is a second way to write CSS in the HTML and that's directly in the <head> in a <style> block:
<head>
<style>
h1 {
color: #333;
font-size: 24px;
line-height: 36px;
}

p {
color: #000;
font-size: 16px;
line-height: 24px;
}
</style>
</head>
That does indeed make the HTML easier to read, already making it better than inline styling. Still, it's hard to manage all styles this way because it has to be managed on each and every webpage of a site, meaning one "quick" change might have to be done several times, depending on how many pages we're dealing with.
An external sheet that can be called once in the <head> is usually your best bet.
The Sheet is Important
I hope that you're starting to see the importance of the sheet by this point. It's a core part of writing CSS. Without it, styles would be difficult to manage, HTML would get cluttered, and the cascade would be nonexistent in at least one case.
The sheet is the core component of CSS. Sure, it often appears to play second fiddle to the first "S" but perhaps that's because we all have an quiet understanding of its importance.
Leveling Up
Now that you're equipped with information about stylesheets, here are more resources you jump into to get a deeper understanding for how CSS behaves:

Specifics on Specificity - The cascade is a confusing concept and this article breaks down the concept of specificity, which is a method for how to manage it.
The latest ways to deal with the cascade, inheritance and specificity - That's a lot of words, but the this article provides pro tips on how to manage the cascade, including some ideas that may be possible in the future.
Override Inline Styles with CSS - This is an oldie, but goodie. While the technique is probably not best practice today, it's a good illustration of how to override those inline styles we mentioned earlier.
When Using !important is The Right Choice - This article is a perfect call-and-response to the previous article about why that method may not be best practice.

CSS Basics: The Second “S” in CSS is a post from CSS-Tricks
Source: CssTricks


Reclaiming my blog as my thought space


Last week, I shared my frustration with using social media websites like Facebook or Twitter as my primary platform for sharing photos and status updates. As an advocate of the open web, this has bothered me for some time so I made a commitment to prioritize publishing photos, updates and more to my own site.

I'm excited to share my plan for how I'd like to accomplish this, but before I do, I'd like to share two additional challenges I face on my blog. These struggles factor into some of the changes I'm considering implementing, so I feel compelled to share them with you.

First, I've struggled to cover a wide variety of topics lately. I've been primarily writing about DrupalCoin, Acquia and the Open Web. However, I'm also interested in sharing insights on startups, investing, travel, photography and life outside of work. I often feel inspired to write about these topics, but over the years I've grown reluctant to expand outside of professional interests. My blog is primarily read by technology professionals — from DrupalCoin users and developers, to industry analysts and technology leaders — and in my mind, they do not read my blog to learn about a wider range of topics. I'm conflicted because I would like my l blog to reflect both my personal and professional interests.

Secondly, I've been hesitant to share short updates, such as a two sentence announcement about a new DrupalCoin feature or an Acquia milestone. I used to publish these kinds of short updates quite frequently. It's not that I don't want to share them anymore, it's that I struggle to post them. Every time I publish a new post, it goes out to more than 5,000 people that subscribe to my blog by email. I've been reluctant to share short status updates because I don't want to flood people's inbox.

Throughout the years, I worked around these two struggles by relying on social media; while I used my blog for in-depth blog posts specific to my professional life, I used social media for short updates, sharing photos and starting conversation about wider variety of topics.

But I never loved this division.

I've always written for myself, first. Writing pushes me to think, and it is the process I rely on to flesh out ideas. This blog is my space to think out loud, and to start conversations with people considering the same problems, opportunities or ideas. In the early days of my blog, I never considered restricting my blog to certain topics or making it fit specific editorial standards.

Om Malik published a blog last week that echoes my frustration. For Malik, blogs are thought spaces: a place for writers to share original opinions that reflect "how they view the world and how they are thinking". As my blog has grown, it has evolved, and along the way it has become less of a public thought space.

My commitment to implementing a POSSE approach on my site has brought these struggles to the forefront. I'm glad it did because it requires me to rethink my approach and to return to my blogging roots. After some consideration, here is what I want to do:
Take back control of more of my data; I want to share more of my photos and social media data on my own site.
Find a way to combine longer in-depth blog posts and shorter status updates.
Enable readers and subscribers to filter content based on their own interests so that I can cover a larger variety of topics.
In my next blog post, I plan to outline more details of how I'd like to approach this. Stay tuned!
Source: Dries Buytaert www.buytaert.net


Features as Apps

One of the most important things that I’ve learned when it comes to building technology products, especially at the super early-stage, is the reality that designing a real MVP (Minimum Viable Product) is incredibly difficult to do.
I’ve already talked about this once or twice on this blog before…

The challenge of keeping things MVP-ish is real and they mostly stem from these two issues / challenges:

The availability of robust frameworks and APIs make it far too easy to (accidentally) scale a simple experiment based on a simple hypothesis into more than just a simple MVP.
It is psychologically difficult to minimize, constrain, and limit our “vision” of what could be with what should be, especially with so many existing examples to compare to (and the availability of great tooling – see #1).

Practice, a shit-ton of discipline, and a hyper-judicious pragmatic framework are necessary to stay trim, stay lean, and to execute the smallest technological experiment possible.
And having an exceptionally-focused cofounder / partner / team is also a very useful and practical counterweight to keep one from moving beyond what is absolutely, fundamentally necessary.
Consequently, in my own practice, I’ve started to internalize a particular mantra that I haven’t really heard before… maybe I’ll coin the term and see if anyone challenges me on it… 
The term is “Features as Apps” and it is the philosophy and practice of building single-serve apps to see if real users will, in fact, use that particular “feature” that might exist in the much larger, future-state application.
I’ll give you an example…
After we had built a small-yet-growing community @ The Bitcoin Pub we began to hear from our users that they wished “this” and “that” existed within the forum itself. Some examples were:

Charting tools for technical analysis for cryptocurrency
More communication tools (e.g. real-time chat)
Notification systems for pricing data
Deeper integration with news sources
Calculators and conversion tools
Buying / Selling of cryptocurrencies
And many, many more…

Instead of spending a significant time building additional features within the larger framework of software we decided to deploy “Features as Apps” into the wild, putting together much smaller apps and websites to validate if these requests were real and true.
As a result, we built things like CoinPuffs and CryptoYum (soon to be released) and even experimented on the “Features” themselves, essentially, Features of Features as Apps.
A great example is CoinPuffs where we recently added a small site off of the main site that allows users to create and establish email alerts for cryptocurrency pricing:

You can easily create a new email alert via the button and then manage them in a simple backend interface:

The question, of course, is whether folks would actually use it (or not). If they do, then, we can roll this feature into the much larger application layer of either CoinPuffs or even The Bitcoin Pub.
There’s not a lot of risk associated with creating these super-small, single-serve apps that serve as features for much bigger software projects. It just takes time and a serious commitment to testing one’s hypothesis over a given amount of time.
If it works out well then you’ve created more goodwill with your customers, deeper lock-in, and hopefully a high return on investment.
I like this model and it allows us to experiment with high-velocity too which, in turn, creates a lot of momentum. These things, of course, are our greatest strengths and it is our greatest asset as a early-stage startup.
The post Features as Apps appeared first on John Saddington.
Source: https://john.do/


Observable

Observable launched a couple of weeks ago. As far as I understand, it’s sort of like a mix between CodePen and Medium where you create "notebooks" for exploring data, making nifty visualizations.

Check out this collection of visualizations using map integrations as an example. The entries are not only nice demos of the libraries or technology being used (i.e. D3, Google Maps, Leaflet, etc.), but also make for some interesting infographics in themselves.
In a note about this interesting new format, founder Mike Bostock describes a notebook as “an interactive, editable document defined by code. It’s a computer program, but one that’s designed to be easier to read and write by humans.”
All of this stuff riffs on a lot of Mike’s previous work which is definitely worth exploring further if you’re a fan of complex visualizations on the web.
Direct Link to Article — Permalink
Observable is a post from CSS-Tricks
Source: CssTricks


CSS Grid Layout Module Level 2

The second iteration of CSS Grid is already in the works and the public editor's draft was released last week! While it is by no means the final W3C recommendation, this draft is the start of discussions around big concepts many of us have been wanting to see since the first level was released, including subgrids:
In some cases it might be necessary for the contents of multiple grid items to align to each other. A grid container that is itself a grid item can defer the definition of its rows and columns to its parent grid container, making it a subgrid. In this case, the grid items of the subgrid participate in sizing the grid of the parent grid container, allowing the contents of both grids to align.

The currently defined characters of subgrid items are particularly interesting because they illustrate the differences between a subgrid and its parent grid. For example:
The subgrid is always stretched in both dimensions in its subgridded dimension(s): the align-self/justify-self properties on it are ignored, as are any specified width/height constraints.
In addition to subgrids, aspect-ratio-controlled gutters and conformance are also defined in the draft and worth a read. It's great to see so much momentum around grids!
Direct Link to Article — Permalink
CSS Grid Layout Module Level 2 is a post from CSS-Tricks
Source: CssTricks


Common Connected Hardware Blunders

Over the last few years we’ve worked with a number of startups who have engaged with Viget for help designing or engineering some aspect of their connected product. Every product is unique, but it may surprise you how similar their challenges are. What is perhaps less surprising is the number of inventive ways we’ve seen solo-entrepreneurs, young startups, and even internal business units with firm foundations go about solving those challenges. I’ll take a moment to reflect on some of those challenges and specifically call attention to the missteps and follies we commonly see early-on in engagements.

Building the wrong prototype
Viget builds primarily two different kinds of product prototypes. A stakeholder prototype, which focuses on delivering desired functionality by leveraging as many pre-existing solutions as possible. And a functional prototype, which focuses on exploring production options by honing in on core mechanics and functionality. Both prototypes serve specific needs which often correlate with the natural phases of product development. Sometimes the prototype should support buy-in for an idea, other times it should help sell the path forward.
In both situations the prototype is the center of attention. The prototype is what you share with your team, your boss, investors, and your crowd-sourced customers (even your mom!). Because of the spotlight, it needs to behave in ways that put a good foot forward. This is why we’re so surprised when we come across cobbled-together assemblies that supposedly represent a product vision. It might only work because it gets cast alongside a tremendous number of conditions and explanation. I.e: 
“...ignore this part, focus on this, let me articulate this thing by hand to show you want it WILL do...”
We admire the gumption and eagerness to make things — especially from our clients — but instead, consider the alternative: a self-evident prototype. A prototype that stands up on its own and clearly articulates a vision. A good litmus test is what you’ll find when you crack open the enclosure of a connected prototype. Is it something you are proud to share? Or is it a rat's nest of wires with indeterminable purpose? Why not invest the extra time, and the extra money, and dedicate some effort to articulating an effective product vision? Build the prototype that serves its specific purpose and can survive being the center of attention. Anything less and you are wasting time by building the wrong prototype.

Waiting for perfection
Developing connected products, like anything, is a balancing act. Wait too long and over-build a prototype and you’ll become overly invested in one direction. A tempering thought to keep in mind: every day spent on product integrationis a day not on the market. Future you is absolutely going to miss out on that revenue.
Finding the right balance stems from experience. Very plainly, it’s important to figure out which features are necessary for achieving present business goals. This gets complicated, fast, because those objectives change. Connected products benefit from a maturing market which will support any number of value-add services, and business want the flexibility to explore and ultimately choose the right one.
Take a look at Helium as an example. This team has iterated for well over three years on a concept where the underlying technology has morphed just as often as their business. Over time they have developed strong relationships with their community, their customers, and their investors -- demonstrating an ability to not only deliver useful products to the customers they have today, but also develop products for the customers they want tomorrow.

Restless Bill of Materials
Another source of pain I see are business decisions which needlessly accelerate product evolution. A good example is the price of a bill of materials (BOM) conflicting with business or marketing objectives.
Consider a fully-developed production-prototype built on the back of specific MCUs, peripherals, toolings, and plastics. The cost of adjusting this BOM late-stage is significant, not to mention a collective headache. However it is a common occurrence because around the time that something is ready to enter production its total in-the-box cost can be scrutinized. It is around this time a product team will receive an email along these lines:
“We’re trying to keep the device costs down to x, we hit a snag here and so we’re currently at y, anything we can we do?”
The product team will take a good look at low-hanging fruit already earmarked as extravagance.
“We’re currently platformed on x but can go to y which costs z less. But it means we’ll need to re-develop portions of the firmware, re-route this, calibrate that, etc”
Unlike software, hardware is generally less forgiving to constant tweaks and adjustments. It’s an all around better thing to simply nail to the wall correctly the first time. But that is obviously a hard mark to hit, so what options exist?
Go to market regardless with the higher price point.Go to market with the lower (desired) price point. Take it out of the margin, or eat it. Make it up with scale or an equally performant but lower cost v2 in the future.Account for the long-term upside of value-add cloud services (subscription, etc).
I really like options two and three, businesses that maintain a price point and develop margins over time. This is complex to model, and more complex to convey to investors or other stakeholders. However, it keeps the right priorities in place: ship early, develop value-add services, cultivate relationships with suppliers.
Ultimately a restless BOM is indicative of teams not truly collaborating together. There are strategies to hurdle specific challenges, and even aid with hardware versioning, but if the BOM is constantly changing there is little opportunity to build valuable services on top a hardware foundation. And, based on our experience, those value-add services are what matter the most to a connected product businesses.Hit a snag manufacturing your connected product? Tell us about it below or contact us.


Source: VigetInspire


Conflicts are rarely just about the cards on the table


Most disagreements aren’t just about the cards on the table. They’re just as much about who’s at the table. What time the game is being played. The last fifty games before this one. And about all the other people the current participants ever played with as well.So it’s no wonder the game ends up making little sense to folks who think everything they need to know to make the winning argument is reading the cards facing up.One good way to tell how much a conflict is about those cards, or about something else, is to gauge the temperature of the tone. If it’s unreasonably, disproportionately hot, then it’s probably not just about the current specifics. There are very few specific situations and details that’ll make people hit the red zone on the account of those alone.People get worked up by compounding circumstances and repeating dynamics. Like, why does he always have to say it like this! Or, can’t she see how this is just yet another example of this other thing we’ve talking about so many times?It’s not at all uncommon for the context to dwarf the particulars. But it’s exceedingly common for people to be oblivious to the fact. And before you know it, the argument ends up boiling over, while a proxy war of disagreement is waged.This is one of the reasons why it’s so rare for online arguments between strangers to go anywhere productive. Unless the topic of discussion can be reduced to purely logic points — and really, what topic can? — you’re going to have to engaged with all the extracurriculars. But how can you, if you don’t know what they are, because you don’t know the other person’s circumstances or experiences?At least if you’re invested in the other person, like if you work, live, or play together, you can spend the time to learn their circumstances and examine their experiences. Once you learn the context, the where-are-they-coming-from, you can start to make progress together on that hot topic. And by the time you’ve bothered to dive that deep, the whole thing has probably cooled off enough for gentle hands to touch.Conflicts are rarely just about the cards on the table was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


Source: 37signals


New in Basecamp: Improved Schedule Cards


A more complete picture of what’s coming upThis was a classic case of “How hard could it be?” that started as a series of customer requests and bug reports. People wanted to see their events AND their dated to-dos on their Basecamp 3 Schedule cards. Totally reasonable, right? Like anything involving dates, timezones, and computers, it took more than a little wrangling… But now you can!Let There Be To-dosHere’s a great example from our Ops Team. Before, we only showed upcoming schedule events. That triggered a misleading message that said “Nothing’s coming up!”Nothing’s coming up! Maybe?Why is this misleading? If you click through to the Schedule itself, you’ll see there’s actually a to-do due tomorrow:Surpise!You wouldn’t have known that glancing at the Schedule card. With the changes we just added, you’ll now see something like this when you’ve got upcoming to-dos:Voila! Just like the full ScheduleWho and When?Another thing was missing from the previous design: It wasn’t clear exactly who was involved in an event and precisely when it was happening. That’s because we just showed the name of the event and the date on which it occurred:What time is dinner, anyway?Now, we show avatars for each participant and to-do assignee as well as times for events that happen at a specific time:A lovely group and an early start.TemplatesProject Templates were also missing to-dos. That led to situations like this where the Schedule looked blank:Nohting to see here… Or is there?In fact, there may have been several to-dos:The full pictureWe hope this makes Schedule cards more useful for you. Stay tuned for more updates to Basecamp 3!Got feedback or ideas to share? We’d love to hear what you think about the new features. You can contact us on Twitter or share your thoughts via our Support form.New in Basecamp: Improved Schedule Cards was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


Source: 37signals


Cultivating an Inclusive Culture


The honest introspection and continuous work for a better teamReconsider DiversityThe typical approach to diversity in corporate environments can usually be summed up in two ways: lazy and superficial.To be fair, diversity is a difficult word to put into action. Most attempts to do so will probably end up feeling superficial. For example, companies often ironically state that they’re “committed to diversity” when the word itself is pretty noncommittal. The ambiguous nature of diversity means it can be interpreted in a number of different ways.That laxity is an allowance for laziness. Initiatives based on diversity are notorious for having vague, or non-existent, standards and accountability. Diversity has become a clichéd ideal versus an agent for change.Diversity is a difficult word to put into action.Attempts to execute diversity in a more specific way can also be problematic. Companies confronted with unfavorable demographic numbers and public pressure to do better find it easy to reach for tokenism as a quick-fix reaction to being called out and as a way to gain brownie points. The addition of individuals from minority and underrepresented groups has become the preferred way for organizations to portray improvement.When someone is perceived as a diversity hire, that label and perception of them as other (i.e. not like me) will be a difficult roadblock for everyone involved to overcome in order to work effectively as a team. Inevitably, the burden is placed on that individual to demonstrate their sameness, perpetuating the common expectation that individuals fall in line and assimilate in order to belong. So instead of an organization evolving from the unique contributions each person can offer, things remain essentially the same.#WOCinTechIn the article Stopping the Exodus of Women in Science, the Harvard Business Review describes the science, technology, and engineering fields as the “Alamo — a last holdout of redoubled intensity” when it comes to machismo in corporate settings. If that statement seems hyperbolic, consider that over half of highly-qualified women in STEM positions — 56 percent— eventually leave the industry. The top reasons cited for their exit? Inhospitable work cultures and isolation.Despite statistics like this and well-documented personal accounts that indicate an environment of intolerance and aggression, tech companies commonly describe their culture as the complete opposite — open and accepting.In Carlos Buenos’ observation of tech’s startup culture, Inside the Mirrortocracy, he offers an explanation for why there’s often such a disparity between a group’s perception of itself and the realities experienced by those that exist there:The problem with gathering a bunch of logically-oriented young males together and encouraging them to construct a Culture gauntlet has nothing to do with their logic, youth, or maleness. The problem is that all cliques are self-reinforcing. There is no way to recalibrate once the insiders have convinced themselves of their greatness.After adopting the abstract ideal of diversity as a value, a group can get the premature satisfaction that their awareness also equals progress. The pursuit to “increase diversity” usually shifts the focus outward for a solution and encourages the mindset that we should eventually arrive at a certain point of achievement. Both of those popular approaches makes it too easy for companies to continue avoiding the real issue.They aren’t forced to confront the biased ways of thinking and behaving ingrained in their culture that have created and sustained such a monolithic environment.If a company truly wants to be a place that includes people that aren’t all alike, they’ll need to create an inclusive culture. That will require an honest look inside themselves to identify the parts of their culture that prevent inclusivity.Recently, companies have seemed comfortable tackling unconscious bias in hiring. On the other hand, they seem unwilling to acknowledge the presence of that very same bias in their everyday operation.There is no known way to avoid unconscious or implicit bias.In fact, it thrives because you’re unaware that it’s happening. That’s why relying on just the good intentions of treating everyone in an inclusive way will always fall short. You will need to make specific plans to combat biased behavior.The work of inclusivity, like our persistent biases, should be constant and never-ending. Your entire team will need to become invested in doing the day-in and day-out work.Inclusivity: We Want You HereBeing inclusive means being consistent about communicating the value of every person participating with our actions. The foundation of those actions should be built on a collective mindset that goes beyond tolerating differences, to truly appreciating them. That appreciation is fostered with the recognition and treatment of differences as the asset they are to a team.When differences are celebrated, everyone on the team will feel safe, supported, and valued being themselves. The freedom of no longer needing to be a certain way in order to be accepted is a major key. Communication is open and honest, instead of guarded. Interactions with each other are earnest and real, instead of strategic. This kind of communication will elevate your work. Here are the actions you can take to make it clear that each person is welcome to participate and their contributions are valued.Safety to Speak UpEveryone on your team should feel safe voicing their concerns and questions. As with other parts of life, rules or guidelines aren’t enough to produce a safe environment. An open door policy in your employee handbook won’t cut it.True safety begins when we take steps to protect what we value. If you value hearing everyone’s voices, start by genuinely supporting one another when an issue is raised. Support isn’t about coddling or other empty gestures. It’s simply meeting someone’s voice with respect and thoughtful consideration.Beyond supporting those that speak up, everyone has the responsibility of being diligent stewards of the environment. Sometimes that means stepping up to advocate for someone else and that requires us to stop being silent.Violent responses to someone speaking up is what makes an environment unsafe. Common responses include intimidation, retaliation, or shaming. Reasons like self-preservation, obliviousness, or agreement with the offending party make it easy to do nothing when someone’s safety to speak up is threatened with violent communication.Silence reinforces fear to everyone, including yourself, and perpetuates avoidance. That can lead to disastrous outcomes when there’s a glaring problem no one feels comfortable addressing.It shouldn’t feel like an act of bravery for a teammate to say when something doesn’t feel right. It should feel like everyone’s expected duty.Gain New PerspectivesMaking speaking up a healthy and normal part of your culture is just the start. Listening is paramount. It’s no good encouraging people to speak, if we aren’t willing to listen.If you’re quick to dismiss or invalidate thoughts and experiences that don’t mirror your own, you’re depreciating the value of your team.Diverse teams perform better because of their access to an abundant and varied supply of thoughts, ideas, and approaches. Recognize and utilize the invaluable resources found in each other!Go into conversations with lots of curiosity and the intention to discover something you hadn’t considered before. During the course of that discussion, you can decide on the best way to move forward as a group. In every discussion you have as a team, don’t just say that questions and differing viewpoints are appreciated. Watch out for exclusion and bias within those discussions as well. Women often report that what they say needs to be repeated or affirmed by someone else in order for it to be heard.The point of discussions like these isn’t about changing minds or determining who’s right. You’re gaining a new perspective, not sacrificing your own.Make Information Easily AccessibleIn an effort to avoid red tape, tech companies in particular can be averse to written policies or guidelines for operations. That approach allows bias to go unchecked. It makes inequitable treatment more likely to occur and harder to point out and defend against.That’s especially true when it comes to how performance is measured. In the absence of clear and consistent standards, success at a meritocracy becomes an uncertainty that’s dependent upon judgement.Documenting your processes not only keeps you objective, it keeps your team empowered and well-educated.Sharing what you know with everyone is a step toward being transparent with one another. Sometimes, information just naturally stays within the confines of a certain team, group of people, or person. Documentation makes any holes in your process obvious when it may not have been otherwise. It helps dissolve information barriers opens the flow of information.That flow of information inevitably leads to a greater level of connectedness. Connecting and building relationships across workplace boundaries, for example, with someone from another team, location, or seniority level, is a great way to counteract exclusivity within an organization.Internal mentorship and sponsorship initiatives are credited with reducing the likelihood of burnout and increasing employee engagement and retention.Illustration: Ashley BoweWe Make Each Other BetterFocusing on inclusivity will force your team to evaluate if your actions honor the existence of everyone there. That question can’t be answered with words or by a single person.It can only be answered in the mindfulness reflected in our actions every day.Yes, it is constant work that requires taking the time to be generous with empathy and thoughtfulness. That work doesn’t hinder productivity, though — it drives it.When your differences are no longer points of contention, they become a celebrated strength. When you choose to uplift each other with respect and support, it elevates your interactions and, as a result, your work.It emphasizes one of the best parts of belonging on a team: We’re all in this together.I’d love to hear your thoughts! What steps have your company or organization taken to be more inclusive? Let me know on Twitter or in the comments below.Cultivating an Inclusive Culture was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


Source: 37signals


Ideas and Your Health


One of the first tweets that I ever “liked” was this one via Aaron Levie:

via @levie
People’s reaction to ideas:
Bad ideas: “That’ll never work”
Good ideas: “That could work”
Great ideas: “That’ll never work”
I’ve seen this play out many times in my short professional career and I imagine I’ll see this dynamic many times over before I’m done.
I ask myself all the time which reaction I’m getting the most from folks (and how quickly those reactions change). Particularly, in bitcoin and blockchain, I’ve seen this switch happen at lightning speed.
Seems all too crazy one day and then the next day folks believe that it could be possible. Maybe we’re all mental.

Or, at least I am.
The post Ideas and Your Health appeared first on John Saddington.
Source: https://john.do/


Copywriting Q&A: Why Brand Voice Matters So Much

Copywriting is a craft with a lot of moving parts. One of the easiest to forget—and also, interestingly, easiest to disregard—is the brand voice. Today, we’re talking about what makes the brand voice so important.
Today’s question is from Frank P., who asks, “Do businesses really care that much about a brand voice? How much of that should I consider when I’m applying to work for them?”
So, the short answer is: Yes. Businesses very much care about their brand voice. It needs to be a major factor in whatever you write for any client.
As for the longer part of the answer, here’s why:
When the internet was young, (baby internet here) companies could just put their products out there and people would buy it. There was very little competition and people were still amazed at this whole idea of buying products and services over the net.
Fast forward to today, of course, and things are VERY different. Our internet has grown up into a surly teenager.
Competition is fierce – and not just for sales, but even for attention! The market is flooded with companies that look alike and probably even do or sell something similar.
And, in one sense, that’s good – it means that there is a market for what that company is selling.
But that competition makes also building and growing a business very hard. It’s getting harder and harder for people to distinguish between one company and its competitors.
It’s even harder for them to understand what a company does differently.
And a target audience they can’t immediately understand what makes a company different and special, they’re not going to buy. No matter how much a potential customer needs what that company has to offer and is actively searching for a solution, they won’t buy from that company if they don’t know what makes them different; if they don’t understand that company’s unique benefit.
A company can have the most beautiful website in the world, the most stunning photography, and the coolest graphics, but if their message doesn’t connect with their audience and spell out why that needs to purchase from them instead of anyone else, that company won’t be successful.
People look at a company’s website and photos to see if it seems professional, but they read the copy to see if they connect with them, to see if the company has experience in the business, to see if they can trust the company, and to see if they want to buy from that company.
One of the best ways for a company to set itself apart and encourage those purchases is by crafting an effective brand voice. A brand voice is the tone and style of the copy that’s used in every piece of messaging.
It’s a brand’s personality.
A brand voice is what helps people connect with a company – what makes the company feel like a group of real, living and breathing people to them, instead of just some amorphous Business-with-a-capital-b with a website. Think about it: Do you want to buy from a stranger, or do you want to buy from a friend?
The personality that a business infuses into is messages—no matter how big or small that business is—is what sets it apart and what makes people connect with it.
Your turn! What are some companies with great brand voices? Let us know your favorites in the comments below!

Source: http://filthyrichwriter.com/feed/


CSS Basics: The Syntax That Matters & The Syntax That Doesn’t

When you're starting to play around with CSS at the very beginning, like any other language, you have to get used to the syntax. Like any syntax, there are a bunch of little things you need to know. Some characters and the placement of them is very important and required for the CSS to work correctly. And some characters are more about clean looking code and generally followed standards but don't matter for the CSS to work.

First, so we have the terminology down:
A CSS ruleset consists of a selector and delcaration(s) wrapped in curly braces.
Important: Braces
All CSS rulesets must have opening and closing curly braces:
braces.header { padding: 20px;}.header padding: 20px;}.header { padding: 20px;}.header padding: 20px;
If you miss the opening brace, CSS will keep reading as if the next bit of text is still part of the selector. Then it's likely to find a character like : which are invalid as part of a selector and break. Breaking likely means it will screw up itself and the next ruleset, and recover after that.
Missing a closing brace is a bit worse in that it's likely to mess up the rest of the entire CSS file unless it somehow finds a double closing brace and can resolve that first missing one.
Overall point: braces are very important!
Preprocessing languages like Sass and Less offer a syntax feature called nesting. This can be convenient, but note that when these preprocessors run and produce CSS, that nesting is removed because CSS by itself doesn't support that. If you copy nested CSS into regular CSS, you'll have problems with the braces.
Sometimes Important: Spaces
There are just a few places that spaces are important in CSS. One of the most imortant is in selectors. One space in a selector means you're selecting descendants of the previous part of the selector. The selector body p means "select p elements that are descendants of the body element". That space means a lot. Hopefully it's clearly different than bodyp which won't select anything (there is no <bodyp> element). But it's not different from body p. Multiple spaces mean the same as one space.
spacesbody ul libodyulli.header .title.header .title.header .title.header.title≠≠=
You can't put spaces in properties, function names, or anywhere you name things. Adding spaces in those situations effectively changes the names, breaking them.
spaces-3background-image: url(tiger.jpg);background - image: url(tiger.jpg);background-image: url (tiger.jpg);@keyframes goRoundAndRound { }@keyframes go-round-and-round { }@keyframes go round and round { }:root { --theme main: red; --theme-second: red;}body { background: var(--theme main); background: var(--theme-second);}
Other than that, spacing doesn't matter much in CSS.
spaces_1.header { padding: 20px;}.header { padding:20px; } .header {padding: 20px; }.header{padding: 20px; }.header{ padding: 20px;}.header{padding:20px;}
I'd encourage you to be consistent with your spacing, and produce clean and readable CSS. You might want to reference some CSS style guides out there for some formatting best practices.
Even the !important rule in CSS, which comes after a the value in a delcaration like body { background: white !important; } doesn't have any spacing requirements. It could have any amount of space before it, or none.
The removing of space in CSS is actually a best practice for performance, so you might notice that when peeking at the raw CSS of websites in production.

You're better off leaving that minification of CSS to a tool that processes your CSS for you, leaving the original alone. We'll have to cover the options for that in other post.
Mostly Important: Semicolons
Each declaration in a ruleset (a property and value pair) ends in a semicolon. That semicolon is required, otherwise CSS will keep reading the next property as if it's part of the value of the previous declaration.
semicolons.header { padding: 20px; max-width: 600px; background: black; color: white}.header { padding: 20px; max-width: 600px background: black; color: white;}
You can leave off the semicolon on the last declaration in a ruleset. I'd warn that doing so manually will cause more trouble than it's worth, and best left to minification tools.
Important: Avoiding Stray Characters
This is important in any language. Every character in code matters, so random other characters will almost certainly break things.
extra-chars.header { padding: 20px;}.header { { padding: 20px;}.header { padding: ~20px;}.header { /padding: 20px;}
Not Important: Line Breaks
A line break is treated like any other white space in CSS, so feel free to use them as needed, as long as it doesn't break any other spacing rule like we talked about above.
line-breaks.bar { background-image: url(texture.png), url(tiger.jpg); }.button::after { content: ">";} .header { box-shadow: 0 0 5px rgba(0, 0, 0, 0.5), 20px 2px 5px -5px rgba(0, 0, 0, 0.5);}

All in all, CSS syntax isn't so hard. Good luck!

CSS Basics: The Syntax That Matters & The Syntax That Doesn’t is a post from CSS-Tricks
Source: CssTricks


The Bigger Man


I spent some time mentoring a younger gentleman the other day and he’s in the middle of some tough professional choices.
He’s a founder of a company that is having gasp … founder problems.

We chatted for quite some time and one of the things that no business school could teach you is how to be the bigger man and walk away.
And I know that it’s never “that simple” and there are a ton of (somewhat) legitimate reasons to “fight on” and ensure that everyone gets their fair treatment and outcome…
… but my counsel to him was to consider the cost, especially as wasted resources of time, money, and energy, and emotion that would / will inevitably rob him and his next project.
In other words, the time he would have to spend working through these seemingly-irreconcilable differences could be better spent recovering, reflecting, and then investing in the next thing.
I’m trying to teach my kids to do the same; this idea that we’re not responsible for how other’s react to us and their judgments to or against us. Our job is to focus on what we can control, our emotions, our attitudes, our actions and how that effects other people.
We can only look ourselves in the mirror, every single morning and every single evening, and ask ourselves if we behaved in right ways and thought honorably about those we worked with and served. We can’t ask that for others, despite how much we may want to.
This pill is tough to swallow but I felt it was an important alternative-route, perhaps, for the gentleman to consider and take. Moving toward any form of litigation or arbitration will only get more messy.
The folks who end up being the bigger men (and women) ultimately are the ones who grow faster and who accelerate harder toward their next project and season of life. This is because they are also, simultaneously, folks who can make hard decisions, decisively.
The post The Bigger Man appeared first on John Saddington.
Source: https://john.do/


Stimulus

A modest JavaScript framework for the HTML you already have.
This will appeal to anyone who is apprehensive about JavaScript being required to generate HTML, yet wants a modern framework to help with modern problems, like state management.
I wonder if this would be a good answer for things like WordPress or CraftCMS themes that are designed to be server side but, like any site, could benefit from client-side JavaScript enhancements. Stimulus isn't really built to handle SPAs, but instead pair with Turbolinks. That way, you're still changing out page content with JavaScript, but all the routing and HTML generation is server side. Kinda old school meets new school.
Direct Link to Article — Permalink
Stimulus is a post from CSS-Tricks
Source: CssTricks