It includes the horizontal scroll for filters on mobile, but it commented out in the CSS for the time being.
It includes the horizontal scroll for filters on mobile, but it commented out in the CSS for the time being.
It includes the horizontal scroll for filters on mobile, but it commented out in the CSS for the time being.
Sure we can do that, but then the user have to type out what they want and it don't see that as very mobile friendly...
site: or date: in any mainstream search engine. Why do you bring this up here?
@prologic and other, when we got a way to store the data about list for each user and functions to view and edit them, I will continue working on the UI:)
@prologic and other, when we got a way to store the data about list for each user and functions to view and edit them, I will continue working on the UI:)
https://git.mills.io/yarnsocial/yarn/src/branch/lists_ui
EDIT: Aha it for adding a feed to a list. cleaver đ
So it would be a feature next the the follow-button maybe
EDIT: Aha it for adding a feed to a list. cleaver đ
$ doing here? 
Do you or anyone else got some opinions or feedback before i start coding?
live on the same link as before (just scroll down;)
e
e
Ha I've just notic that code blocks already work this way and it got a nice border around it which we could render on mobile
Ha! I've just notic that code blocks already work this way and it got a nice border around it which we could render on mobile
e
Ha! I've just noticed that code blocks already work this way and it got a nice border around it which we could render on mobile
.filer-nav element from <main> or use some absolute position to make it work. I also seen some implementations with a gradient fade to each side.
I would go for putting the filters in an
<aside>-menu and the make it collapsible on mobile. Maybe make a setting for pinning some filters like Mentions entions and then have the other hidden under a "More..."-label
not sure if I fixed the issue yet or just created more problems...
Not sure how the two would work together though is that is at all possible
Not sure how the two would work together though is that is at all possible
I would have expected it to look like it does in the app when I wrote the posts, but yarnd collapsed it allo into one blockquoute, which intrired to fix by adding
(...)Is this a problem with the markdown parser not being the same used in the app and in yarnd?
>Software doesnât become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. Youâre not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that thereâs a bit of quality assurance.
>(...)
> Often software starts with dogfooding founders, with features that solve their personal problems.
>(...)
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.
>Software doesnât become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. Youâre not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that thereâs a bit of quality assurance.
> Often software starts with dogfooding founders, with features that solve their personal problems.
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.
>Software doesnât become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. Youâre not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that thereâs a bit of quality assurance.
> Often software starts with dogfooding founders, with features that solve their personal problems.
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.
>Software doesnât become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. Youâre not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that thereâs a bit of quality assurance.
> Often software starts with dogfooding founders, with features that solve their personal problems.
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.
>Software doesnât become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. Youâre not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that thereâs a bit of quality assurance.
> Often software starts with dogfooding founders, with features that solve their personal problems.
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.
> With software itâs clear: when you donât have programmers, you donât get a computer program. But when a team is employed to develop a product without designers, a design gets made nonetheless. Accidental design. Bad design, most likely. But with no designer around and no one listening to users, the client is not going to notice.
> Great design isnât done by picking up a tiny issue and creating a solution for it. Itâs done by gaining deep understanding for the problems people have, the context in which they use products and by testing solutions with people. Itâs labor-intensive and requires people who are engaged with their users over long periods of time.
> In volunteer-to-volunteer situation, they just have to hope someone feels like doing it. If the frontend developer is like, âYeah, but I like it the other wayâ, designers are shit out of luck.
> With software itâs clear: when you donât have programmers, you donât get a computer program. But when a team is employed to develop a product without designers, a design gets made nonetheless. Accidental design. Bad design, most likely. But with no designer around and no one listening to users, the client is not going to notice.
> (...)
> Great design isnât done by picking up a tiny issue and creating a solution for it. Itâs done by gaining deep understanding for the problems people have, the context in which they use products and by testing solutions with people. Itâs labor-intensive and requires people who are engaged with their users over long periods of time.
> (...)
> In volunteer-to-volunteer situation, they just have to hope someone feels like doing it. If the frontend developer is like, âYeah, but I like it the other wayâ, designers are shit out of luck.
> With software itâs clear: when you donât have programmers, you donât get a computer program. But when a team is employed to develop a product without designers, a design gets made nonetheless. Accidental design. Bad design, most likely. But with no designer around and no one listening to users, the client is not going to notice.
(...)
> Great design isnât done by picking up a tiny issue and creating a solution for it. Itâs done by gaining deep understanding for the problems people have, the context in which they use products and by testing solutions with people. Itâs labor-intensive and requires people who are engaged with their users over long periods of time.
(...)
> In volunteer-to-volunteer situation, they just have to hope someone feels like doing it. If the frontend developer is like, âYeah, but I like it the other wayâ, designers are shit out of luck.
Doodle.com uses
(â) for their middle level called something like yes if needed vs just â for yes
Doogle.com uses
(â) for their middle level called something like yes if needed vs just â for yes
