OP here. Iit's telling that so many people are commenting in this thread about how Slack isn't that bad because you can customize it to be less attention-grabbing. The fact remains that Slack is engineered to be attention-grabbing out of the box. Sure you can tweak it to make it less shouty, but Slack is still a product that is sold for money by a company. It's not in their interests to make it align with your existing workflow if they can upend that workflow entirely. No one's making money from you having a meeting or sending a well thought out email, so I think it's worth being cynical when considering paid alternatives.
I think it's also worth remembering that for hacker type folks like us, customizing software is the norm. But default settings are default for a reason, and they will inevitably end up being the most commonly used. When everyone else in your company expects you to use Slack they way do, i.e. for 8 hours a day with instantaneous reply times, then it becomes hard to push against that and eventually it becomes the status quo
> The fact remains that Slack is engineered to be attention-grabbing out of the box. Sure you can tweak it to make it less shouty
But this is kind of an absurd critism. Who wants a real-time business-oriented operations chat system where you don't know about incoming messages by default? Can you imagine people complaining about not knowing about new messages for minutes and support staff having to inform people that you have to turn those on manually? Slack wasn't engineered to suck you in, it's acting in the only rational and useful default for what it is, a standard established by every chat client I've ever heard of before it. It would have been a product that didn't work by default. If slack was missing a seeing you wanted, I could understand, but at some point you're just blaming a chat tool for being optimal for chats because your organization wants you to respond unreasonably quickly or because you're not muting channels or snoozing or not using the settings to the fullest.
I'm very sympathetic to that line of argument, I'm no fan of capitalism, but choosing the default settings for something like Slack (whether you are selling it in order to make a profit or not) appears to me to be a tradeoff between making it immediately useful, and obvious to non-nerds why it is useful, and being less attention-grabbing when your team gets a bit more unwieldy. I've no doubt there's more they could do and more care they could take, but Slack do publicise the customisations you can make.
(In an ideal world of course we'd be using a chat system that has a great user experience, is based on open standards, _and_ is somehow easy to deploy... but within our current economic system that is clearly a tricky one.)
OP here. I think the problem is that when tools like Slack are engineered in such a way as to make people dependent on their product, it's unfair to expect users to accept all the responsibility of mitigating against that. Software companies aren't using organizational productivity as a benchmark for their success, just usage statistics. So no, Slack doesn't enforce a single way of working, but it is engineered to consume as much of people's time as possible, for better or worse.
Jason Fried wrote his in his (much more comprehensive) post about group chat pros/cons:
"It’s common in the software industry to blame the users. It’s the user’s fault. They don’t know how to use it. They’re using it wrong. They need to do this or do that. But the reality is that tools encourage specific behaviors. A product is a series of design decisions with a specific outcome in mind. Yes, you can use tools as they weren’t intended, but most people follow the patterns suggested by the design. And so in the end, if people are exhausted and feeling unable to keep up, it’s the tool’s fault, not the user’s fault. If the design leads to stress, it’s a bad design."
> I think the problem is that when tools like Slack are engineered in such a way as to make people dependent on their product
It's a chat client. It's an addictive medium. It sounds to me like you're shooting the messenger.
Skype, Hangouts, or any IM client wants your attention. Slack is just a better version of all the other IM clients I've used (for work).
If you don't want to be disturbed you close Slack.
I suspect that if you've got problems with Slack, it means that there's a problem in the culture of where you work.
Where I work, individual @ mentions are barely used, maybe 0-5 per day. But there's nothing that's written in stone, or ever been discussed, it's just that colleagues respect each other's focus. Then the rest is less important that all can be ignored unless you're not concentrating on something.
> I suspect that if you've got problems with Slack, it means that there's a problem in the culture of where you work.
One can work somewhere that has a problem in the culture, and Slack can make that worse. It's been interesting to me to observe when my company changed from hipchat to slack, my productivity went down until I recognized how slack was messing me up (because of the default UI patterns it came with) and I've had to unwind that by changing a bunch of settings and patterns.
It's been a similar change when I moved from a company that used email and tickets for team communication, to one that uses chat.
Yes, the culture if the heart of the problems, but the tools can amplify those problems.
It's like if you can't cut a piece of wood effectively with a handsaw, but I give you a power saw, you may soon have much bigger problems on your hands. (or hand, if you really mess it up)
> I think the problem is that when tools like Slack are engineered in such a way as to make people dependent on their product, it's unfair to expect users to accept all the responsibility of mitigating against that.
You write this as if it's a given. I never said anything about mitigating against dependency... I'm talking about mitigating against a dysfunctional organization, which are far more common than I think most people realize, or (especially) care to admit.
> Software companies aren't using organizational productivity as a benchmark for their success, just usage statistics.
Again, I'll accept that software companies care about the number of active users even over productivity, but it's not a given that Slack cares (at all) about how much time I actually spend on Slack (as opposed to, for example, Facebook).
> So no, Slack doesn't enforce a single way of working, but it is engineered to consume as much of people's time as possible, for better or worse.
If you show me that Slack is trying to monopolize people's time (something that, quite honestly, would be bad for its business and product) then we can talk about how much responsibility a user has to mitigate a product's designed purpose. Otherwise, I'm speaking about how much accountability a user is willing to assign to his or her organization because, quite frequently, people are unwilling to point out things they find wrong within an organization.
> Jason Fried wrote his in his (much more comprehensive) post about group chat pros/cons:
I find a lot wrong with Jason Fried's writing in general, and this post isn't different. That quote specifically falls into one of his common issues, oversimplification to the point of absurdity.
If a design leads to stress it's bad design? Well what if communicating one-on-one with your boss about things you're accountable for stresses you out (something that is fairly common)? And since Slack is designed to make that pretty easy, is it Slack's fault you're stressed? Is Slack poorly designed because you are? No. That's an organizational issue.
AEM Developer, Mid-level to Sr | New York, NY | Contract | Onsite
We're Big Human, a reputable digital product design studio near Union Square in New York.
We are looking for a talented AEM developer to lead a major project for a well-known international media client. The successful candidate will be working from our office as part of a small, dedicated team for a 4-6 month engagement.
The successful applicant will work closely with other members of our dev team (including other AEM developers) to create and configure AEM templates and components, help design an architecture solution to support multiple sites and provide support and troubleshooting during testing.
Other requirements:
- Located in NYC or willing to relocate
- 3+ years of development experience using AEM / CQ
- Experience with AEM v6.1 Touch UI
- Java-based skill-set with extremely thorough understanding of AEM building blocks, templates, custom components, dialogs, widgets, custom workflows, Digital Asset Management (DAM) customization, and development / deployment processes
- Experience designing and building RESTful APIs
- Ability to translate marketing needs into AEM specific recommendations & solutions
- Knowledge or desire to learn Adobe Analytics and Adobe Target
- Has worked in an agile environment
- Need to work with onsite team members and offshore team members to define, elaborate, and develop features and requirements
Big Pluses:
- Front end experience
- Understanding of other Adobe cloud services that can be implemented with AEM
- SEO knowledge
- Client-facing communication skills
AEM Developer, Mid-level to Sr | New York, NY | Contract | Onsite
We're Big Human, a reputable digital product design studio in New York. We’re looking for an engineer who can lead all AEM development projects for our team.
The job would require implementing and managing each project (including 3rd party integrations), building new AEM websites, and working closely with internal product development. You would coordinate with other lead members of our dev team to implement and integrate best practices of AEM usage, as well as provide support and troubleshooting during testing. Ideally you would have suggestions for how to enhance existing business applications using Adobe, and are able to identify requirements early-on during scoping & discovery phase of a project.
Our client for this project has a strict NDA; sorry we can’t tell you more! We’ll spill the beans during the application process.
Other requirements:
- Java-based skill-set with extremely thorough understanding of AEM building blocks, templates, components, dialogs, widgets, and development / deployment processes
- Experience designing and building RESTful APIs
- 3+ years of development experience using AEM / CQ - Experience with AEM v6.1 Touch UI
- Ability to translate marketing needs into AEM specific recommendations & solutions
- Can leverage AEM to solve cross-departmental challenges
- Knowledge or desire to learn Adobe Analytics and Adobe Target
Big Pluses:
- AEM 6 Architect Certification
- Complete understanding of other Adobe cloud services that can be implemented with AEM
- SEO knowledge
- Desire to help drive the development team forward
- Client-facing communication skills
To apply, please email Caitlin at jobs@bighuman.com
AEM Developer, Mid-level to Sr | New York, NY | Contract | Onsite
We’re a reputable digital product design studio in New York. We’re looking for an engineer who can lead all AEM development projects for our team.
The job would require implementing and managing each project (including 3rd party integrations), building of new AEM websites, and working closely with internal product development. You would coordinate with other lead members of our dev team to implement and integrate best practices of AEM usage, as well as provide support and troubleshooting during testing. Ideally you would have suggestions for how to enhance existing business applications using Adobe, and are able to identify requirements early-on during scoping & discovery phase of a project.
Our client for this project has a strict NDA; sorry we can’t tell you more! We’ll spill the beans during the application process.
Other requirements:
- Java-based skill-set with extremely thorough understanding of AEM building blocks, templates, components, dialogs, widgets, and development / deployment processes
- Experience designing and building RESTful APIs
- 3+ years of development experience using AEM / CQ
- Experience with AEM v6.1 Touch UI
- Ability to translate marketing needs into AEM specific recommendations & solutions
- Can leverage AEM to solve cross-departmental challenges
- Knowledge or desire to learn Adobe Analytics and Adobe Target
Big Pluses:
- AEM 6 Architect Certification
- Complete understanding of other Adobe cloud services that can be implemented with AEM
- SEO knowledge
- Desire to help drive the development team forward
- Client-facing communication skills
To apply, please email Caitlin at b9b5a82e@opayq.com
Big Human - New York City (Union Square) - Front-end Developer
We're looking for an experienced (4+ years) front-end developer. We're an agency that works with a wide range of clients from Time Inc to Jetsetter to small startups you've never heard of. We're all Javascript all the time - Express and Backbone/Marionette power most of our sites at the moment.
You have: a deep understanding of CSS, HTML and Javascript (not just jQuery), pre-processors and Grunt/Gulp. Knowledge of front-end frameworks is useful, React is a real plus.
We have: competitive salaries, unlimited PTO, flexible hours, Metrocards, lots of social events, free gym and Citibike membership and plenty more
Big Human - New York City (Union Square) - Front-end Developer
We're looking for an experienced (4+ years) front-end developer. We're an agency that works with a wide range of clients from Time Inc to the Winklevoss Twins to small startups you've never heard of. We're all Javascript all the time - Express and Backbone/Marionette power almost all our sites.
We need someone who has a deep understanding of CSS, HTML and Javascript (not just jQuery), uses pre-processors and Grunt/Gulp. If you've worked with Backbone and Marionette before, that's a real plus.
Big Human - New York City (Union Square) - Front-end Developer
We're looking for an experienced (4+ years) front-end developer. We're an agency that works with a wide range of clients from Time Inc to the Winklevoss Twins to small startups you've never heard of. We're all Javascript all the time - Express and Backbone/Marionette power almost all our sites.
We need someone who has a deep understanding of CSS, HTML and Javascript (not just jQuery), uses pre-processors and Grunt/Gulp. If you've worked with Backbone and Marionette before, that's a real plus.
I get the idea of not creating a massive playlist but I think more than three would be good - I wanted to create a downtempo/ambient playlist and had at least seven tracks in mind. I think 7-9 would be a good number.
I think it's also worth remembering that for hacker type folks like us, customizing software is the norm. But default settings are default for a reason, and they will inevitably end up being the most commonly used. When everyone else in your company expects you to use Slack they way do, i.e. for 8 hours a day with instantaneous reply times, then it becomes hard to push against that and eventually it becomes the status quo