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.