Could you provide built-in Custom CSS support, just as WordPress does?


#1

I’m more and more relying on Dynalist, but the interface doesn’t serve my purpose very well, so I installed a Chrome Extension called User CSS and customized some part of the PC browser interface, see the screenshot below:

However this still doesn’t serve my purpose completely, what I really want to see is:

  1. Apply the customization everywhere, including Mobile App / PC Browser / Desktop App
  2. Apply the customization to the Shared Links, as the following screenshot suggests:

Could you provide this feature for Pro Users?


#2

There’s an existing feature request for this here: https://trello.com/c/yERFbB25/158-custom-css

It would address point 1 but not 2 though. What the anonymous visitors see is the default setting right now, and we need to a way to let them access your preferences. That’s a separate feature.


#3

Personally not a big fan as working on the feature takes away development time from product features.

I see the areas of focus for the Dynalist team as:

  1. Core product features (main audience)
  2. Pro-style features (power users)
  3. Tinkering additions (tinkers & geeks)

That’s in the order of audience size. The more time is spent on features for number 3, the more Dynalist becomes a fringe product, leaning and catering towards the geek audience. On the other hand, the more time and focus is on stuff “everybody” wants to and can use, the bigger Dynalist grows :slight_smile:

The way I see it, custom CSS is one of those things we love to tinker with where normal people don’t even know what the abbreviation stands for, let alone how to apply it :slight_smile:

Compare: Evernote has email-to-evernote functionality (power users) but no custom CSS fields.


#4

Great points, @ruud!

The way I see it right now is that it’s okay as it saves us more time in the long run, plus it’s technically not hard to do (i.e. low-hanging fruit). And the way to avoid confusing “main audience” is to hide is make it hidden like the options under “Advanced options” so most people won’t be bothered by it.

The reason I think it might save us time in the long run is that instead of trying to explain to people why we only have 3 font sizes or why the dark theme can’t be lighter, we can just show them the way so they can customize it. Even if we don’t implement any of the suggestions they propose, over time responding to those “why can’t the UI be like this” requests take a lot of time.

I hope that makes sense!


#5

Makes sense. Same reasoning I have for IFTTT support on the API. Instead of implementing every request, 90% of special requests can be handled by IFTTT recipes.


#6

When will you make Custom CSS / Dynalist API online?

I really want to build some type of “Card Sharing & Reading System” based on Dynalist. And the “Dynalist Card Set” will be different from a WeChat’s post or Twitter Msg because I can provide some carefully organized sub-cards along with the first card which attracts the reader into a story/thinking/solution context.

Currently I cannot control how the shared list appear in front of other people’s face, but if you provide custom css, I can ask people to apply a CSS codes into his account. Dynalist API will be better, because I can have more freedom on how to present the Online Reading & Commenting Interface. :blush:


#7

I guess custom CSS is more useful, since API only gives you data.

I feel like it’s a waste of time for you to construct the entire list (and make them editable too), just for attaching different CSS to it. Or do you just want the visitors to see a static view of the document in your own CSS? In that case it makes a lot more sense to make use of the API rather than custom CSS.

Unfortunately we don’t have a detailed timeline for it. We’re trying to fit alpha plugin system (which includes custom CSS) in the first half of 2018. I hope we can get there! :sunny:


#8

@Erica you’ve spoken about a plugin system a few times but after searching I don’t see any description of it. Can you elaborate a little? Is this something the users can develop, say with Javascript and/or CSS? Something like Powerpack?


#9

Yeah, users can develop JS (for plugins) and CSS (for styles), and others can choose to load plugins and styles in their Dynalist across devices.

I just realized that we didn’t provide any descriptions for it, and one of the major reasons that we’re still thinking about how it would work. Things like how to prevent users from submitting nasty code that steals people’s content or mine bitcoins on other people’s machines. And how would bug reporting work differently, since now in addition to all kinds of browser extensions that already cause some issues, we’ll have code that directly interacts with Dynalist and may cause errors at any time.

We might post something when we have thought through all these cases and how to deal with each of them.

Thanks for asking!


#10

Tamper/Greasemonkey and Stylish/Userstyles but built for the Dynalist service specifically?


#11

Ideally more discoverable (you can browse all plugins), and with more control/screening to minimize risk.

Greasemonkey and Stylish would work right now (although maybe not cross platform). A large amount of work will be restructuring our code to expose a clean interface for developers to work with.

Right now all the extensions like Powerpack are hacks (no offense!). Given the current way Dynalist is written, you’ll need to do lots of hacks and browsing and maybe testing to write something as powerful as @Piotr’s Powerpack. We hope to make that a lot easier with a plugin system.

For example, instead of hacking together a settings UI, you can simply tell Dynalist that you want to add a few setting options for your plugin and from there you can retrieve and set the value of that option from a Dynalist interface. That makes plugins less likely to “break” with an update, since we have taken into account the interface that they use.

I hope that makes sense.


#13

I’m very much for custom CSS :heart:

For me, it would get rid of two mildly annoying problems:

  1. Using dark theme, code rendering using backticks looks ugly to me. With custom CSS, I could adjust that easily.
  2. Image size. Some images are larger than the current screen. Then they are displayed only partially. I would set them to 100% text width and be happy.

And, @Erica, I had no idea how many markup requests you got. Looks like with custom CSS, your life would be easier. Also, experienced users could help those beginning ones in the forums without needing your attention.


#14

@Viktor_Papara @Erica I agree. The ability for custom CSS alone allows for significant customization of the UI without exposing users to security risks. This is one feature I liked at Checkvist. They allow Pro users to define custom CSS in the settings page. Its simple, but does the trick, and I would guess from an engineering standpoint is not a crazy amount of work for the programming team.

The one thing to keep in mind, the CSS has to work also on the mobile platform (like the IOS client). I think one of the things many users will customize is how tags appear. I have a custom CSS that highlights the line based on the priority level with a color, but in non-obtrusive color feedback.

screenshot3

This is what the markup looks like:

Next Actions
   Task with priority 1 #p1 
   Task with Priority 2 #p2 
   Task with Priority 3 #p3 
   all other tasks

#15

@Viktor_Papara @Chris_Kunicki

Definitely! Allowing custom CSS would resolve lots of markup requests that we have. Especially the ones on desktop app and mobile apps since Stylish doesn’t work any more.

An interesting and also scary thing I recently learned is that CSS is not 100% secure: https://github.com/maxchehab/CSS-Keylogging It never hurts to be more careful than needed :slight_smile:


#16

@Erica that is wild. thanks for sharing it. I guess you probably have to have some css scrubbing to filter out possible issues.

Though at the end of the day, it will have to be the responsibility of the pro user to only use safe code (or if they get code, to know what they are requesting).

Can’t wait for CSS support :slight_smile: Sorry for all the requests. Dynalist is so great we just want it to be better and better.


#17

As a start we could disallow requesting any external resources in CSS, so information won’t leave the page, at a minimum. Unless you want a custom font or a custom background image, this doesn’t really hurt anyone.

From there we can see how we can relax the restriction without compromising security. Just a thought.

Don’t worry! We totally understand. And thanks for taking the time to help Dynalist become better! :blush:


#18

I assume this means customizing appearance of nodes? I had a vision of having a CSS recipes document I could download as a Dynslist doc, and then do something to activate named styles. And then apply those either by menu or by #tag magic.

Does any of this resemble the plan for CSS?

Aside: while i would take advantage of more styles if that became easy, at present I only use one CSS hack: making the +/- button always visible.


#19

We imagine there are two stages:

Stage 1: you can write your own styles

It’s simple, there’s a text box where you can copy paste CSS style from other places. On the web it’s the same as using Stylish – the only advantages being that it’s persistent across all platforms including desktop app and mobile app, and that you can sign into Dynalist on a public computer and still have your styles.

Stage 2: use other people’s styles

Here, we’ll let people publish their own styles, with a name and description for what it does. Maybe also with an option. The goal is to have the creators make the styles as modular as possible, rather than putting all their personal styles into one snippet.

That way, if the creator likes big bullet points and small fonts, you can reuse big bullets points without having your text small.

You will be able to use several styles, and order them (if there’s a conflict, the last one overrides previous styles). Each style can be updated by the creators.

There’s no #tag magic involved the way we imagine it.