Where the design community meets.
California, USA co-founder at finesse.io Joined over 8 years ago
Hi, I'm one of the (two) founders of finesse.io. We built this tool because, as designers, we wanted to be able to contribute our design changes directly, but had to resort to either drawing mockups, sitting with developers and pixel-pushing, or installing the whole back-end on our computers. With finesse, you just open the browser, make the changes directly, and get your version of the website. We've been using this technique for a while on some big and small projects, and now want to bring it to everyone. We've built version 1 and are inviting those who signup as quick as we can.
The debate around designers coding has been overdone but the result is that there are plenty of designers enjoying the empowerment that code brings to their workflow. Finesse.io lets you make small tweaks to existing code, or sweeping re-designs - we wanted it to be both a tool for experienced designers, and those just getting started with CSS / SCSS / ...
As a bonus added extra we took the opportunity to make the tool a code editor that's focused on the front-end - so it includes an inspector, remote live-reloading of styles on all preview devices whenever you make changes, and an easy-to-use code commit tool, so designers can participate with developers straight to github, etc if they want to.
Thanks for taking a look and appreciate any feedback you may have.
except what if I see an offer / product I was interested in but didn't have time to read, or noticed just as I was clicking away. Now I go back to the page and it's not there anymore...
The other reason to dislike sliders is that they take attention away from the rest of the page - do you want the user to scroll from left to right through your slider or scroll up and down. I don't think many will do both.
I see some benefits in but the negatives outweigh them IMO. don't you miss the freedom for each element to define specific 'breakpoints' that are appropriate for its unique content, where any of its styles can change?
For example a flexbox container whose children have a max-width of 410px but you only want event numbered columns. Normally for this, I would define 100% width by default, change to 50% when viewport size is calc(410px * 2 - margin * 4), and change to 25% when viewport size is double that. Would you create more repeatable (but probably never repeated) classes for that, or introduce custom component.
I think BEM and its variants are a much nicer solution, and even easier to maintain consistency. https://css-tricks.com/bem-101/
Also I could be interpreting this wrong but the last article you point to ends with "It’s important not to take this too far; classes should be abstracted but ideally not presentational. Classes like .round-corners for the sake of SRP are really not all that advisable."
But I do love your styleguide, how it looks and what it represents for your design and development process, and the example it sets for others. So, congratulations for that.
Square just launched their API. I think it's supposed to be stripe-like. They are the people who do the physical iPad device thing at a lot of stores
This doesn't say it's a sponsored post on mobile.
This is not the same at all as the Sass variables. CSS variables are so much more powerful. Read the article, especially the bit about media queries (and also the bit about inheritance) and tell me you don't think this will make your stylesheets so much more maintainable and awesome!
Can anyone see any difference between the iMac and the iMac Retina graphics?!
"Where should we send the kit to?" | Your email address | SEND
Haven't heard of a download link, or they want to harvest email addresses?
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.
You've absolutely hit the nail on the head in terms of describing the need. I've been in teams with that frustrating workflow and that's exactly the problem we're trying to solve.
Right now we're focused on sites that are comfortable with securing their code with an (authenticated) cloud provider, a la github. For the simple reason that we're proxying websites, and (optionally) pulling and pushing your code from somewhere, so they need to be accessible to our servers. You can provide authentication details in a couple of different ways according to how secure you want to be (we can do ssh keys even) and we have security and IP rights principles laid out in our terms. However, I'm fully aware relying on a SaaS isn't for every company, and I can't rule out a standalone product in our future if there's the demand, and we can still provide the value in that scenario.
Thanks for your feedback Andy, and please stay in touch!