Forem: Dawid Cedrych

My friend shared a great link last week, here it is...oh, wait.

Dawid Cedrych — Thu, 23 Jan 2020 23:54:49 +0000

Dude, have you had a chance to check that great UI tips website I sent you last week?
Ugh, yeah, it's great... (Have no clue what website he is talking about)

Hey, can you resend me that link to a blog about fundraising we talked about last week?
Sure, let me see where did I send it...Slack, Telegram, Twitter, LinkedIn...?

This is a great post, you gotta check it out!
Cool, will save it for later
Nope, check it now, you will forget!
I won't!

(7623 days later, still haven't checked)

If any of these scenarios sound familiar, I think you know what's on my mind.
I think it's a serious problem that:
a) We share great content with our friends and they never check it because one cannot remember to check every link shared on each medium.

b) You remember your friend shared some great content a few weeks back but you have no idea how to find it (ok, you can spend an hour on searching the browser's history, but that's not a solution too)

c) There are no real incentives to change that habit, we got used to bookmarking and saving for later anytime we can, but rarely get back to revise it.

If you feel me, I want to hear from you. I guess I have an idea for an app that might solve it 🤭

Or maybe you already use some system to manage things people share with you?

2020 Goal: Organize my notes and internalize knowledge by writing short essays.

Dawid Cedrych — Tue, 07 Jan 2020 18:08:49 +0000

While listening to various software and tech podcasts, I find tons of great insights. Sometimes between the lines, sometimes in seemingly unrelated shows.

Over time I collected lots of quotes and notes from episodes I listened to.

My New Year's Resolution is to revisit and compile them into short essays.

While doing such, I am connecting the dots between seemingly unrelated notes and explore common concepts.

Writing it down in the form of an essay requires additional research and helps internalize the knowledge.

Sharing it with you is learning in public, which is also one my 2020 goal :)

Here is the link to my publication
https://altabits.substack.com

If you have tons of notes and little incentive to organize and learn from them, try this approach!

Feedback Request: Startup Essays powered by Podcast's Quotes

Dawid Cedrych — Fri, 03 Jan 2020 20:46:35 +0000

At the beginning of 2020, I'm in the mood of starting some new content series and a related newsletter.

As I'm an avid podcast listener, I collect my personal cherry-picked quotes from shows I listen to. These are mainly episodes about software, entrepreneurship, startups and business.

I was thinking about just sharing a few quotes per issue, but I suppose niching down the scope of each edition might make more sense.
There are tons of great insights that are spoken in a collateral "thinking-out-loud" manner, usually in shows you wouldn't normally look for them.

Looking for ways to provide value to readers, I came up with the following format:
I pick one theme concept/piece of wisdom and write a short narrative supported by quotes I got from podcasts.

My idea is to curate and combine them in a coherent, themed series.

I think the target audience includes indiehackers, founders, entrepreneurs, and VPs of product.

To get you a sneak peek of what I'm up to, here is a draft of the first essay:

Look for existing market momentum

It might seem counterintuitive, but being an innovator or, even worse, an evangelist is not crucial to building something people want.
Often, you will be much better off entering the existing market where others already paved the way. It is known as "The Last Mover Advantage", and it entails also avoiding r&d cycles your competitors have already failed at.

Marc Andreessen, in a16z podcast episode "Why We Should Be Optimistic the Future" points out that this pattern is more common than we think

"Every successful technology I'm aware of, you know the things that are like all of a sudden like the next big thing like the iPhone in 2007 or just an example, they all have this incredible 25, 40 or 50 years backstory to them that you sometimes have to go back and excavate."

As other examples, Mark mentions video conferencing technology that first surfaced in the 1960s, first smartphone concepts by RadioShack from 1982, or even fiber optic technology, which has its beginning in 1840 in Paris.

Marc concludes that

It's less a question of what the new idea is, as it turns out the idea is probably already out there somewhere.

These were the examples of succesful hardware, that have been around quite for a while before it actually took off. Can we find similar cases in the software industry?

David Cancel, CEO of Drift suggest that Slack is the best example of the right market timing with a relatively little innovative product. The interview he gave in Software Engineering Daily episode is spot-on

There are different technologies that we use but, Slack is from a use case standpoint is not different than IRC 25 years ago, right? I often show people inside our engineering and product team who don't know what IRC is, and never used it, a screenshot of an IRC client from 20 years ago and then Slack next to each other and they're blown away. They're like, “It's exactly the same. Everything is the same.” They have never seen that. I'm like, yeah.

I remember IRC, do you? :) Anyway, it's interesting how many messaging communicators existed before Slack, but somehow none of them managed to achieve such high market share. Sure enough, Slack has done particular things incredibly well, such as an API-first approach and allowing for multiple third-party tools integrations. Still, the core functionality wasn't something new.

We had technology like that 25 years ago, but we had subscale markets as a million of us using it, or five million or whatever the number was. Now billions are using. The reason it matters is that the behavior change has already happened. It's now normal and now you can build something in a much larger ecosystem, and I think for entrepreneurs and engineers who want to build something really pay attention to is there momentum already in the world happening that I can apply this to, versus trying to create your own momentum from scratch.

We arrive at the conclusion - leveraging existing market momentum is a shortcut compared to being someone who starts the momentum. Getting back to Marc Andreessen talk, I think the following line from the mentioned a16z podcast serves a good wrap up:

It's less the question of when it's going to work, it's more the question of when it's going to work right

Do you find it valuable? Is there anything you'd change? Would you subscribe to get it to your inbox every two weeks? If it sucks, tell me why :)

I'd love to hear your feedback. Thanks in advance! :)

I started a new series of curated content articles and would love to get your feedback!

Dawid Cedrych — Mon, 16 Dec 2019 14:05:03 +0000

Here is the first issue

https://altalogy.com/blog/alta-curated-1/

Each week, I curate 6 items - 2 podcasts, 2 readings and 2 videos.

I believe as long as you poke around technology, entrepreneurship, software, or philosophy, chances are the content will be closely aligned with your preferences too.

This is not about the latest trends or news. I know that sharing only timeless wisdom is a hard-to-achieve virtue, but I’ll do my best to find the best possible middle ground.

I'd love to get your feedback!

A case for productive note taking

Dawid Cedrych — Thu, 12 Dec 2019 17:54:21 +0000

You probably know this feeling when something inspiring, interesting, or generally exceptional pops into your head. I have the instant urge to jot it down to make sure it won't go away. And that's exactly what I usually do.

Despite having Notion, Evernote, and many other note apps, I always end up with an uncategorized list of random, out of context sentences in the apple notes app. That makes it difficult to get back and review them later on, not to mention reflecting on particular ideas.

My Apple Notes app screenshot

The reason why I have such a mess in my notes is quite simple: Launching a more sophisticated app like Evernote, taking a note, picking the right notebook, tag, or category is friction.

I wonder whether you have this problem too?

I'd like to stop for a moment and make one thing clear - I'm not thinking of another TODO app.

There are various flavors of TODOs. There is a difference between "Buy milk" and "Establish healthy sleep habits". The first is simply a task with a clear definition of completion.
Finding a way to be healthier is rather a long term goal, which should be tackled methodically from various angles.

I think you now know where I'm going.

There is a whole class of notes that are basically ideas you should reflect on over some time. These Ideas convey a lingering value and have the power of habit-forming, changing your mentality, and eventually shaping who you are.

I might have an idea of how to make taking quick, yet essential notes frictionless. But before I even validate the idea, I'd like to ask for your help.

Here are a few categories I identified when going through the notes I took in the last few months:

Quote
EXAMPLE:
"Wealth creation is an evolutionarily recent positive-sum game. Status is an old zero-sum game. Those attacking wealth creation are often just seeking status." Naval Ravikant

Reflection / Thought
EXAMPLE:
"The key to success is doing hard things and explaining them in simple words, never the opposite."

Business Idea / Problem definition
EXAMPLE:
"A podcast app that allows for easy quote taking by tapping on airpods."

Goal
EXAMPLE:
"Reduce my SaaS product churn by 30%."

Wording
EXAMPLE:
"take a page out of (someone's) book."

I'd love to learn what kind of quick yet essential notes you are taking. Are some of them fall into one of the categories above? What are the missing categories, in your opinion?

I'd greatly appreciate your feedback and encourage further discussion. Thanks for reading!

A sneak peek from a backend system architecture guide - feedback request

Dawid Cedrych — Tue, 12 Nov 2019 21:36:45 +0000

You probably know this whole class of queries "What backend architecture should I...?" which always results in the same boring answer:
"it depends".🙈

There are tons of great resources online, and the problem is how to read them all in multiple tabs simultaneously. 🙃

My dear friend Tomasz Antas, CTO of Altalogy, is curating "The ultimate comparison of web app backend architectures" in a form a long blog post with lots of charts, infographics, insights and advices.

I'm posting a sneak peek here for two reasons:

1) If there's anything you would change in the illustration below, I'd love to know now
1) Tomasz got fewer followers than me, so I'm posting on his behalf 😂

Let me know if such an infographic is clear and informative to you. Thanks! 🙏

Client-Side Rendering versus Server-Side Rendering

Dawid Cedrych — Tue, 05 Nov 2019 15:11:03 +0000

Originally posted by Jakub Klimek on Altalogy blog

History of the rendering solution

Since the dawn of the web history, the only way to get your website on the screen was by using SSR. You had to upload your HTML & styles to the server, it compiled everything, and then you were ready to browse with fully populated HTML.

However, these were times where the pages mainly contained pictures and text, like the first website in history → http://info.cern.ch/, which looks like this:

Quickly jumping to nowadays, there's no longer the case. Current sites are closer to web applications like facebook, twitter, or eBay. The world of the web has grown and become more demanding. The needs of users have increased, people want to send messages, get it in real-time, watch videos, have more interaction with the website. Developers have started to render websites on the client-side using frameworks like angular, backbone, ember, react.js e.t.c.

If you are asking yourself which method is better, CSR or SSR - first of all, you have to ask yourself - what do you want to build or achieve?

Learn React?
Create a Single Page App?
Want to build the frontend for a new web application?
Build a website is mostly static?

On this choice, it depends on what you should decide on.

Background

Whenever you open a website, your browser makes a request to the server to get the content of the web - HTML, assets, styles, and the rest of the data.

Request and response speed depends on a few things:

your internet connection speed
distance between you and the server
CDN optimization
how many users are trying to open your site in one moment
how the website is optimized to be loaded

When the webpage is loaded, it can either be rendered in the browser (client-side rendering) or on the server (server-side rendering). Each is slightly different and has its pros and cons.

Client-Side Rendering

What is client-side rendering?

With a client-side rendering solution, when the user opens your website, his browser makes a request to the server, and the user gets a response with a single HTML file without any content, loading screen, e.t.c. It's a blank page until the browser fetches all linked JavaScripts and lets the browser compile everything before rendering the content.

Client-side rendering pros:

Fast render after initial load
Faster navigation
Lower server load
Remarkable for web apps

Client-side rendering cons:

slower initial load
unpredictable performance - you never know if your user will open and 'compile' your website on a mobile device with a very slow internet connection or not updated browser
Client-side routing solutions can delay web crawling.
SEO - if you not implemented correctly
Initial req loads the page, CSS, layout, js,
some or all content is not included

Server-side rendering

What is server-side rendering?

As I mentioned above, - SSR is not a new concept. It has been used since the first backend solution, like PHP or JAVA. Server-side rendering is a method to render your website. When the user opens your page, his browser makes a request to the server, and the server generates ready to provide HTML.

Server-side rendering pros:

SEO friendly - SSR guarantees your pages are easily indexable by search engines
Better performance for the user - User will see the content faster
Social Media Optimization: When people try to post your link on Facebook, Twitter, etc. then a nice preview will show up with the page title, description, and image.
Shared code with backend node
User-machine is less busy
Best for static sites

Server-side rendering cons:

TTFB (Time to first byte) is slower; your server has to spend some time to prepare HTML for your page instead of sending almost empty HTML doc with link to javascript
The server will be busier, can execute fewer request per second
HTML doc will be bigger
The page is viewable sooner, but it's not interactive and the beginning, a user has to wait until react will be done executing
Full page reload after routes change

Example page

To make a comparison of these two methods, let's use a very simple website with one image.

Client-side rendering - code example

Bellow you can check example HTML served to the user in the react application (create-react-app). As you can see there is no image yet, only simple HTML with linked js files.

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8" />
    <link rel="icon" href="/favicon.ico" />
    <title>React App</title>
    <link href="/static/css/main.64d7c8c6.chunk.css" rel="stylesheet">
</head>
<body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
    <script src="/static/js/2.1cca17c9.chunk.js"></script>
    <script src="/static/js/main.234a2bc6.chunk.js"></script>
</body>
</html>

Server-side rendering - code example

Bellow you can check our example website on next.js. As you can see, the main difference is that we already have HTML with image, ready to render.

<!DOCTYPE html>
<html>
<head>
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1" />
    <meta charSet="utf-8" />
    <title class="jsx-3505738252">Home</title>
    <link rel="icon" href="/favicon.ico" class="jsx-3505738252" />
    <meta name="next-head-count" content="4" />
    <link rel="preload" href="/_next/static/6AZVKi7KqSIP8pz3uCg0R/pages/index.js" as="script" />
    <link rel="preload" href="/_next/static/6AZVKi7KqSIP8pz3uCg0R/pages/_app.js" as="script" />
    <link rel="preload" href="/_next/static/runtime/webpack-035ac2b14bde147cb4a8.js" as="script" />
    <link rel="preload" href="/_next/static/chunks/commons.4a179d4644f468f50fbf.js" as="script" />
    <link rel="preload" href="/_next/static/runtime/main-6bef3842d6b2422a0213.js" as="script" />
</head>
<body>
    <div id="__next">
        <div class="jsx-3505738252">
            <div class="jsx-3505738252"><img cassName="img" src="/header.png" class="jsx-3505738252" /></div>
        </div>
    </div>
    <script id="__NEXT_DATA__" type="application/json">{"dataManager":"[]","props":{"pageProps":{}},"page":"/","query":{},"buildId":"6AZVKi7KqSIP8pz3uCg0R","nextExport":true,"autoExport":true}</script>
    <script async="" data-next-page="/" src="/_next/static/6AZVKi7KqSIP8pz3uCg0R/pages/index.js"></script>
    <script async="" data-next-page="/_app" src="/_next/static/6AZVKi7KqSIP8pz3uCg0R/pages/_app.js"></script>
    <script src="/_next/static/runtime/webpack-035ac2b14bde147cb4a8.js" async=""></script>
    <script src="/_next/static/chunks/commons.4a179d4644f468f50fbf.js" async=""></script>
    <script src="/_next/static/runtime/main-6bef3842d6b2422a0213.js" async=""></script>
</body>
</html>

Performance

To understand a nomenclature of the all graphs bellow I will use this image as an explanation, thanks to Google: https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics#user-centric_performance_metrics

CSR performance

Simulated Slow 4G, 4x CPU slowdown

No throttling

SSR performance

Simulated Slow 4G, 4x CPU slowdown

No throttling

Conclusions

both apps become viewable and interactable after 1-1,5 seconds, in this simple example SSR is a little bit faster
in server-side-rendering user will get HTML rendered much faster than in client-side-rendering
in client-side-rendering, non-content can be displayed until browser will download all the js files
DOM Content is loaded much faster in SSR than in CSR; in client-side-rendering, you have to wait to download js
first Contentful Paint is also faster at SSR
a blank page is much longer on client-side-rendering, as a developer you have to avoid it using some loader, or loading screen
image is faster available with SSR compared to CSR, because when using CSR the images cannot be downloaded before linked js files, HTML is not ready,

What should I use?

If you want to build site which is mostly static (blog, portfolio, landing page), use Gatsby, it's not SSR, but it pre-renders the website into HTML at the build time
If you want to build a web app with react, and you care about SEO, easier social media optimization and faster render for user you should think about SSR and framework like next.js
If you building a SPA (single page application), and you don't want to configure everything on the server side like: i18n, router e.t.c. you should use create-react-app

Originally posted by Jakub Klimek on Altalogy blog

Health iOS app redesign sprint in 8 hours. A case study from our internal hackathon.

Dawid Cedrych — Wed, 09 Oct 2019 12:03:21 +0000

Hey everyone!

It's Hacktoberfest, and I'd like to share a case study from our recent internal UX/UI design hackathon!

How many times you came across quite a nice product, with huge potential, but it looked and felt just...meh?

I decided to see if I can fix some of these products one hackathon at a time.

Today we held our first internal hackathon for designers and product owners. The formula is as follows:
1) Pick industry
2) Browse Angel List, Betapage, App Store looking for startups that lack good design but has the potential to become something big
3) Ask the founders for consent to play with it
4) Pick one
5) Let creative people redesign a few screens and make it 10x better within one day.

This time we picked the DeepH iOS app (Healthcare).

Happy reading!

Overview

DeepH app is a general utility health app that encourages a healthy lifestyle by tracking steps, workout, weight, height, meditation time, sleep. The user can sync external data sources (Fitbit, Apple Health, Google Fit) or add entries manually.

Objective

Medical applications often store/process sensitive user data. Some apps feature health insights based on blood pressure, weight, age, or other parameters/risk factors. Needless to say, when it comes to health, credibility and reliability are the most important values that build trust with users.

While most of them are not necessarily concerned with the technical solutions under the hood, they often assess credibility by how the app looks and feels like.

The redesign sprint has been scoped to identify and fix UX bottlenecks and take the user interface to a whole new level of a fully-fledged product.

Goals

Acquire more users
Build a relationship with existing users
Convert free users into premium users

Process

The team consisted of a product owner and a UX/UI designer who worked together for 8 hours to redesign two screens of the application: the main dashboard and fitness data preview.

They collaborated remotely using Slack, Sketch, and Zeplin.

Started with two dashboard propositions, they picked one and polished it to establish a unified design system and elements styling.

Results

Main Dashboard

Grid helps memorize the position of an element and make the dashboard better organized

Key insights

Swap the list for a two-column grid

Lists are pretty good for an ordered collection of elements, especially when the number of them is dynamic. In this case, the grid helps memorize the position of an element and make the dashboard better organized.

Dashboard as data display

Users can now see all relevant data, such as a number of steps, resting heart rate, or workout time right in the dashboard. There's no need for the additional tap to check current metrics. On the other hand, the subtle shadows dropped on tiles encourage to tap and see the detailed metric break down and chart.

More native elements

Obeying Apple design guidelines for bottom tab bar, navigation bar, buttons, labels, fonts, fonts, spacings, paddings makes the user feel familiar and comfortable.

Color palette

Dominant white color, complemented by blue details and subtle shadows, makes for a clean, sleek layout.

Emotional, engaging copywriting

If someone does not hit the full health score, let's motivate him/her to be more active in a friendly way.

Call To Action button to connect data sources

The floating bottom button is more accessible and won't be overlooked on scroll down. Keeping the button title device-agnostic help add more tracker integrations in the future

Each fitness parameter has its own assigned color

Colors help associate and recognize a specific type of information.

Meditation data preview

While bar charts are better for comparison, line charts are better for evolution

Key insights

Change bar chart to a line chart

While bar charts are better for comparison, line charts are better for evolution. Thus, line charts serve better for motivational purposes.

Bold "plus" to add missing entry

Sometimes one can just forget to submit the score of the day. Therefore, the add button for missing entries should stand out.

Engaging illustrations

"Did you know..." section should drive more attention as properly selected pieces of trivia can do magic to form habits to use the app regularly.

Thanks for reading!

Did you like the article and the redesigned views? Post your feedback in the comments section!

To see more of our designs visit out Dribbble profile,
or check our website to learn about our company.
😊

New Service For Early stage Startups - Idea Validation

Dawid Cedrych — Sat, 05 Oct 2019 23:02:55 +0000

It is a common practice among software house companies to offer product design discovery workshops (similar to famous Google Design Sprint) as the first step of the cooperation.

The purpose of such workshops is to brainstorm the idea, prototype it, and propose MVP to create a detailed cost estimate of the project.
The cost varies from $2000 to $7000, depending on the length of the workshops.

I hypothesize that early-stage startups may have misaligned needs and might not benefit from such workshops for several reasons:

They already brainstormed and defined MVP, and even got mockups and clickable prototype, they just need to learn about development costs.
They have a product in mind but haven't thought about the problem it solves. Therefore, all they need at this stage is a brainstorming session with professionals who help them find the right direction; there's no need for prototypes or system architecture blueprint.
Their idea is inherently wrong or impossible to execute. The workshops should conclude after the first hour or so.
They got techies and team members with specific knowledge in-house. They just need wireframes and hi-fidelity mockups

I think such workshops should be customized for every customer while being modular.

The scenario is as follows:
I visit a software house website and compose my workshops based on my needs. I see that wireframes cost X, product canvas costs Y, etc. I select modules and send the inquiry pretty much like cars can be customized online.

Do you think this would be a good idea?

Have you ever attended any paid product design workshops?
If so, do you think there's been anything missing that would undoubtedly increase the delivered value for you as a startup founder?

I look forward to getting your feedback!