Invoice template guideline.

[hql287]

A lot of people asked me how to make custom invoices for Manta. Here's the first step to making the contribution easier. There are only a few constraints that a template needs to satisfy before it can be incorporated into Manta.

Edge cases

1. How does it look with/without a logo? I know a lot of people/business that don't have an official logo to use.
2. How does it look in black and while? How does it look with custom accent colour?
3. How does it look with the items at the top/middle/bottom?
4. How does it look with/ without the recipient information?
5. How does it look with/without note?

Using fonts

1. Please use fonts available in the public domain. Eg Google Fonts,
2. Please choose fonts that support a wide range of languages, not just English.
3. Please don't use Comic Sans, Times New Roman or similar fonts unless you have a very good reason to.

Custom Fields

1. Don't use any custom field that Manta does NOT support. For example, each item does not have a detail description field, users can only put in name of the product/service for that item at the moment. Also, Manta does not have a field for Signature so don't put one in the template.
2. Please use Manta a few times to have a better understanding of the app.

Aesthetic

This's a very subjective topic but I guess at the end of the day, I'll still need to decide which one is good enough to incorporate into Manta. I'll try my best to not sounds like a douche while doing that.

If you're a designer

• You can update your design file here with some screenshots showing how it handles the edge cases.
• Please note which fonts that you use and where we can get them.

If you're a developer

• You're very welcomed to convert the design to HTML/CSS and React components. It's quite easy if you know your way around a React project. The only thing that you need to know in addition of React is 'styled-components` which is also very easy to learn.

If you have any question, please let me know in the comment.

Thanks!

[ghost]

Building a custom theme right now. I think it isn't necessary to split a template into react subcompontents and using styled components, maybe the entry barrier for making a new theme is lower if there's only one component and one css file, perhaps some font files. i will send a pull request once it's finished, then we can look together if that template structure fits for you and what to change. if all goes well maybe we get a new starter template boilerplate out of it.

[hql287]

I think it isn't necessary to split a template into react subcompontents and using styled components

Hey @jens-t. It's true, this depends on how the template is structured. The two current templates are fairly simple but each still has 3 distinct sections: header, main and footer. So it makes sense to split the template into 3 components respectively for organizational purpose.

If the template is simpler (which has only 1 or 2 sections), then probably it would be better to keep them in one component.

Regarding styled-components, it makes the implementation of customization much easier than using plain CSS.

maybe the entry barrier for making a new theme is lower if there's only one component and one css file, perhaps some font files.

As far as creating templates is concerned, then you're definitely right, plain HTML and CSS will be just fine.

i will send a pull request once it's finished, then we can look together if that template structure fits for you and what to change. if all goes well maybe we get a new starter template boilerplate out of it.

This would be great 👍 Looking forward to it. I also have another template that's being designed. Maybe I'll try to keep up with you 😜

[ghost]

Hey @jens-t. It's true, this depends on how the template is structured. The two current templates are fairly simple but each still has 3 distinct sections: header, main and footer. So it makes sense to split the template into 3 components respectively for organizational purpose.

Sure. If you build a theme based on react-components/styled-components, splitting like this makes sense. I meant, it is maybe worth a try to use just one react-component and extract template data transformation, styles and html into different files. if we're talking about templates. Basically just html & s/css, as you mentioned, plus a data transformation plain js file :)

Regarding styled-components, it makes the implementation of customization much easier than using plain CSS.

I know what you mean. But css vars and/or sass make the implementation even easier, if you write your code/styles everyday in this way. But as we're talking about templates it's maybe also more common to the majority.

As far as creating templates is concerned, then you're definitely right, plain HTML and CSS will be just fine.

Yes, just talking about templates :) I looked for a way to structure the template as close as possible to plain html & css, without introducing too much new dependencies. I added two webpack loaders, the raw-loader and the sass-loader(node-sass) so you can require css & sass files into the main template component, and webpack hot reloading and watching files for changes still works fine, if you're developing the templates in the main repository. Maybe one can even simplify that to also drop the react-component that acts as theme wrapper now. for easier template development outside the main repository. i don't know if thats really necessary ... i like the structure i have now.

The data transformation seems a bit overhead, at first, but helps greatly clean up the html/jsx and produce simple template vars, easier to use, if your just editing the html. I'm in progress of creating a refactored business template, so that we can discuss these ideas. it will also be the base for my custom template. the main sub component isn't yet refactored, but if you want to take a look: https://github.com/jens-t/Manta/tree/another-theme .

currently the sass is more or less plain css, i added it for future purposes like creating a textrhythmus and so on. in the current state sass isn't really needed. but to make the css more readable i will split it into sass components later. but you can still include css the same way.

The themename is lopewind, short for envelope window, cause i first intended to design a template which displays the recipient adress on top in the right place for an envelope window. then i saw the fields for recipient address aren't there yet :D Maybe i could use your help to add these, if you think it's ok to have these new fields.

What do you think about the template structure? Is that something we can use as a starting point for developing a new one? Are there things you don't like at all or tips for further improving or simplifying?

Looking forward to your feedback :)

[ghost]

Ok, that bad? :laughing: :see_no_evil:

[hql287]

Ah, sorry! Forgot to add the comment 😜 I actually was waiting for your prototype (as you suggested) so we can discuss this easier. Anyway,

I looked for a way to structure the template as close as possible to plain html & css, without introducing too much new dependencies.

Yes, this should be ideal, so go for it!

Maybe one can even simplify that to also drop the react-component that acts as theme wrapper now. for easier template development outside the main repository. i don't know if thats really necessary ... i like the structure i have now.

It's not necessary but can be very helpful. For example, I had this idea of developing a templating system, where designers can create their own templates with only HTML/CSS and a JS template engine language. Maybe something like Pug, EJS, Handlebar or Mustache? ...

These templates can/should be developed and distributed via their own repositories. The users then download can import it into Manta. It works pretty much like a plugins system.

I didn't have the time to think about it too much but I think if we push your idea a little further we might end up with something like this. The result would be a lower bar to contribute templates to Manta which definitely what we want.

What do you think?

The themename is lopewind, short for envelope window, cause i first intended to design a template which displays the recipient adress on top in the right place for an envelope window. then i saw the fields for recipient address aren't there yet :D Maybe i could use your help to add these, if you think it's ok to have these new fields.

When I first thought about naming templates, I was trying to get fancy as well 😄. However, I soon realized that when there's enough templates, it can be confusing to remember which one is which. The user will need to preview each template to really know how it looks like.

For me, using names that can suggest how the template looks like works best because this is the first thing that the user asks when it comes to choosing a template. For example, if they're thinking "Ok I want this template to look formal and professional, what template should I choose". A template named Business would definitely better than something like Nexus, Wolverine or Blue Water etc.

I'm also making 2 new templates at the moment, one is called Modern and the other one is called Developers. The first one is target towards photographers, designers and the like. The second one, well, it's pretty obvious, isn't it?

So while it's highly recommended to be creative with the design, layout ... I would encourage to keep it simple and to the point when it comes to naming the templates.

Regarding lopewind, I really think it's a cool name, it even sounds great! But to be honest, I wouldn't know how it looks like.

So a screenshot, maybe? 😄

[ghost]

No problem, was just curious :laughing:

I first finish the structure migration and send a PR. The screenshot would show the business theme, cause i'm just refactoring it at the moment, to discuss a proposal of a new template structure with you :)

It's not necessary but can be very helpful. For example, I had this idea of developing a templating system, where designers can create their own templates with only HTML/CSS ...

Why not, but for that we should create a style sandbox for the preview, so that the global styles for the app don't mess with the themes. one could also include the global app styles during theme development outside the mainrepo, but a sandbox would be much better.

... and a JS template engine language. Maybe something like Pug, EJS, Handlebar or Mustache? ...

Maybe just js template literals? The html is not that complicated and has only simple show/hide conditions. But, yeah if you want to decouple template development from the main repo, we have to drop react completely. I really like pug but it's a bit complicated for people that never used it before. And EJS, Handlebar or Mustache seem like overkill for a simple template like this. Maybe there is something simpler ... or as is said just js template literals ...

I didn't have the time to think about it too much ...

No problem, i will make some proposals.

... but I think if we push your idea a little further we might end up with something like this. The result would be a lower bar to contribute templates to Manta which definitely what we want.

Yes, that's my goal with this ...

A template named Business would definitely better than something like Nexus, Wolverine or Blue Water etc.

You're right. Makes it more difficult to find a good name, but it's a good guideline for theme names. Do you think it is a good idea to release, for example a german version of some themes, since there are some differences in how you label things, you can't use a translation for this, it's more a theme thing? Thats what i need, but it's maybe too confusing. Or some themes use german invoice guidelines and others not? Would the name then be "Developer (German)", i don't know. Maybe you have some ideas for this problem.

[abiguzas]

Hi, First of all, I would like to thank you for this great app.

I have two proposals to make.

1. Proposal for a template design. (Made with 'styled-components`) Views with different settings are below.

2. Proposal for additional Input Field

Template default without recipient, with accent color and with logo without logo, with additional (bank account) info.

Proposal for additional input field to type in a bank account info.

Any feedback and criticism very welcome!

[hql287]

@adcat: Hey this is great! 👍 Can you create a separate PR for this template? (as this issue just serves as a quick reference) Thanks!

Also, please create a new issue for the bank account info proposal as well (so we can discuss about its implementation).

[hql287]

Btw, do you have the source file of the design (PSD, Sketch)?

[abiguzas]

@hql287 Ok, I will create PR. The template was made with HTML/CSS and then transferred into working Manta template, so I don't have such source files(:

[hql287]

The template was made with HTML/CSS and then transferred into working Manta template, so I don't have such source files(:

@adcat: No worries :)

[indreklasn]

@adcat Hey! Where can I find the template you created including the Iban?