https://mail.kde.org/pipermail/kdenlive/2016-March/008950.html

Has a ticket been made thowards the sysadmins? can you pleas link it here?

In T2327#33279, @obogdan wrote:

Has a ticket been made thowards the sysadmins? can you pleas link it here?

jb will submit the ticket.

Ok, ticket finally submitted. Not sure if other users than me can see it but will post infos here whenever I get a reply.
https://sysadmin.kde.org/tickets/index.php?page=tickets&act=view&id=UWN-7606

great jb,

hope they respond fast. ;)

Good news, I got an answer. So it looks like Wordpress requires more admin time, but they are ok to create us a Wordpress instance for kdenlive. I will now ask them to go for it and will let you know when it's ready!

They're not wrong there, my WordPress sites are always under brute force attacks. Have to keep an eye on everything to ensure no new plugin vulnerabilities have come out.

In T2327#34067, @mardelle wrote:

Good news, I got an answer. So it looks like Wordpress requires more admin time, but they are ok to create us a Wordpress instance for kdenlive. I will now ask them to go for it and will let you know when it's ready!

fantastic!!!!

The wordpress test instance is now live, work should begin soon.

Now that the main structure is somewhat done I am starting to focus on content and I think we should start to focus on "Features" and then on "About".

Features

This page is to showcase Kdenlive so it should have straight to the point content and great screenshots. Have a look at some content of similar websites for to get an idea of when it is "good" and when it is "bad".

https://www.blender.org/features/
http://ardour.org/features.html
http://natron.fr/features/
https://shotcut.org/features/
http://jliljebl.github.io/flowblade/features.html
https://cinelerra-cv.org/five/Features5.pdf
http://cinelerra.org/2015/index.php/features/editing
https://inkscape.org/en/about/features/

I am thinking of first having the logos and respective links of the technologies kdenlive uses and then move on to describe the features and screenshots.

https://dev.kdenlive.org/features/

Just a minor note, don't know if this is really an issue for potential Kdenlive.org visitors: many web sites have menu navigation that still doesn't work with touch. So, visiting these sites is a pain when using a tablet (Android, iOS, Windows). Even KDE forums don't work correctly when visited using a touch display device.

Do we have already a text for the "Featuure" page?
I guess that before to create the screen shots we have to know what are the features we want to list on the page.
What are the most important and which are less important for creating images based on the text.

For the contact/help topic: we should explain to new users not to flood the bug tracker with distro-specific installation and packaging problems. Lately, we see many useless bug reports with highly specific system and distro combinations. Probably no dev is able to figure out what's wrong with all the broken Kdenlive distro packages out there.

The project maintains its own Ubuntu ppa and I assume this to be the reference if in doubt. For known installation woes I would assume to direct people first to an installation FAQ and then to the Kdenlive forum.

Users should understand that the bug tracking system is for reporting bugs as concise as possible with minimalized regression projects if possible.

In T2327#39370, @thediveo wrote:

Just a minor note, don't know if this is really an issue for potential Kdenlive.org visitors: many web sites have menu navigation that still doesn't work with touch. So, visiting these sites is a pain when using a tablet (Android, iOS, Windows). Even KDE forums don't work correctly when visited using a touch display device.

I can't really test this but i think the theme framework already has some phone and tablet fallback modes...

In T2327#39400, @massimostella wrote:

Do we have already a text for the "Featuure" page?
I guess that before to create the screen shots we have to know what are the features we want to list on the page.
What are the most important and which are less important for creating images based on the text.

There is the one in kdenlive.org but it is very old. Shotcut has a nice one also lightworks has a cool one: https://www.lwks.com/index.php?option=com_content&view=article&id=99&Itemid=210

Just some form the top of my head are:

• 3 point editing
• Advanced trim tools
• Read and write to many formats
• GPU effects (movit)?
• Proxy editing
• Translated to many languages?

In T2327#39412, @thediveo wrote:

For the contact/help topic: we should explain to new users not to flood the bug tracker with distro-specific installation and packaging problems. Lately, we see many useless bug reports with highly specific system and distro combinations. Probably no dev is able to figure out what's wrong with all the broken Kdenlive distro packages out there.

The project maintains its own Ubuntu ppa and I assume this to be the reference if in doubt. For known installation woes I would assume to direct people first to an installation FAQ and then to the Kdenlive forum.

Users should understand that the bug tracking system is for reporting bugs as concise as possible with minimalized regression projects if possible.

There is also this which Sam wrote based on Kritaś

https://userbase.kde.org/User_talk:Cameralibre

Maybe it helps...

In T2327#39414, @afarid wrote:

I can't really test this but i think the theme framework already has some phone and tablet fallback modes...

I've just tested the dev.kdenlive.org link and the current design works on touch devices fine. As long as there are no drop-down menus and hover functionality, touch should always be fine.

In T2327#39416, @afarid wrote:

In T2327#39412, @thediveo wrote:

For the contact/help topic: we should explain to new users not to flood the bug tracker with distro-specific installation and packaging problems. Lately, we see many useless bug reports with highly specific system and distro combinations. Probably no dev is able to figure out what's wrong with all the broken Kdenlive distro packages out there.

The project maintains its own Ubuntu ppa and I assume this to be the reference if in doubt. For known installation woes I would assume to direct people first to an installation FAQ and then to the Kdenlive forum.

Users should understand that the bug tracking system is for reporting bugs as concise as possible with minimalized regression projects if possible.

There is also this which Sam wrote based on Kritaś

https://userbase.kde.org/User_talk:Cameralibre

Maybe it helps...

Added this here:
https://dev.kdenlive.org/bug-triaging

But content needs review.

It's a start, but most people won't read that amount of text and start writing bug reports anyway. So, in my humble opinion, we need a short and concise intro that explains how to write a good Kdenlive(!) bug report.

All the other details are for those who want to make most of bugzilla. Most users won't bother reading all the stuff.

So it should simply say: How to write a good bug report, followed by only three or four important rules. For instance, along these lines:

• steps to reproduce: if the bug can be reproduced using only a few simple steps, this will often suffice. Please make sure that your list of steps is complete.
• minimal example: help the devs to reproduce your problem by attaching a minimal Kdenlive project. A minimal example consists only of the clips in project bin and timeline absolutely necessary. However, please don't attach video or image clips to your report unless explicitly asked to do so.
• stack trace: if Kdenlive crashes, please add a stack trace to your report. A good stack trace...

In T2327#39365, @afarid wrote:

Now that the main structure is somewhat done I am starting to focus on content and I think we should start to focus on "Features" and then on "About".

Features

This page is to showcase Kdenlive so it should have straight to the point content and great screenshots. Have a look at some content of similar websites for to get an idea of when it is "good" and when it is "bad".

https://www.blender.org/features/
http://ardour.org/features.html
http://natron.fr/features/
https://shotcut.org/features/
http://jliljebl.github.io/flowblade/features.html
https://cinelerra-cv.org/five/Features5.pdf
http://cinelerra.org/2015/index.php/features/editing
https://inkscape.org/en/about/features/

I am thinking of first having the logos and respective links of the technologies kdenlive uses and then move on to describe the features and screenshots.

https://dev.kdenlive.org/features/

Farid, the website is looking awesome! Great start, sir! Your logo up at the top left, too.... it just works. :) It'll be great to see it become the new brand logo for Kdenlive when the time comes.

I might offer an encouragement on the features page: I would focus on the core strengths and features of Kdenlive itself before putting any affiliated technologies. If your target audience is video editors, film production studios, professionals, etc., then they're going to be interested in Kdenlive, first, and what IT can do. They need to see what makes it great. Flexible layout, advanced trim tools, timecode, multiple edits in a single project (sort of), GPU processing (once it's perfected -- HUGE feature), keyframe effects... you get the idea. I think that would have a bigger impact on viewers.

Also, I'd make the logo images smaller on the other open source projects, and more uniform in size. I'd also suggest even going as far as writing a brief blurb about what the project does, why Kdenlive uses it, and a link to their website. Community, right? :)

I think it's coming along very nicely. Keep up the good work, mate.

Also, the news page looks really good, too.

Also, I just noticed this on the homepage. Right front and center, bold and big in your face, is the "Bugs" image and link. I cannot, CANNOT discourage this more. The fact that users will see "Bugs" right there from the get go is going to veer away any professional seriously interested, and deter a very valuable part of the video market. Bugs present flaws, weakness, and instability. It's great that you have a link for Bug Reports under the "Get Involved" at the footer on the bottom. Awesome place for it. It's out of the way, but it lets users know that the option is there without having to navigate tediously to find it.

If Kdenlive is going to gain rapport, and subsequently greater support, and even increase the chance for greater funding, it has to have a bold, stable, reliable, functional and useful presence. "Bugs" will kill any chance of that presence in once glance -- I promise you that. The only people that won't be extremely intimidated by this are developers, testers, and techno-junkies. If this is the target audience you're trying to reach with Kdenlive, then go for it. But, please, if you're looking to appeal to any professionals, don't put "Bugs" front and center on the home page.

Alright, I'm stepping off my soap box. :) Again, it's just a strong encouragement, with motives to drive Kdenlive towards greater success. No harm intended.

I was just looking at the new site, and was just about to comment about the HUGE "Bugs" icon on the front page. And on the left... making it even more obvious. But then I saw that @jessed said it better than I could.

Those menus should be something like:

• Download
• Manual / Documentation / Getting Started
• Features

If they should be kept. I'd say that it wold be better to don't use them, have the top navigation bar a a big download button on top of the slide. (Something similar to the blender site)

https://dev.kdenlive.org/features/ does not have links to other "partners", just for MLT.

In T2327#39417, @thediveo wrote:

In T2327#39414, @afarid wrote:

I can't really test this but i think the theme framework already has some phone and tablet fallback modes...

I've just tested the dev.kdenlive.org link and the current design works on touch devices fine. As long as there are no drop-down menus and hover functionality, touch should always be fine.

I don't think this will an issue...

In T2327#39449, @thediveo wrote:

It's a start, but most people won't read that amount of text and start writing bug reports anyway. So, in my humble opinion, we need a short and concise intro that explains how to write a good Kdenlive(!) bug report.

All the other details are for those who want to make most of bugzilla. Most users won't bother reading all the stuff.

So it should simply say: How to write a good bug report, followed by only three or four important rules. For instance, along these lines:

• steps to reproduce: if the bug can be reproduced using only a few simple steps, this will often suffice. Please make sure that your list of steps is complete.
• minimal example: help the devs to reproduce your problem by attaching a minimal Kdenlive project. A minimal example consists only of the clips in project bin and timeline absolutely necessary. However, please don't attach video or image clips to your report unless explicitly asked to do so.
• stack trace: if Kdenlive crashes, please add a stack trace to your report. A good stack trace...

hmmmm, good point but it makes me wonder why krita felt the need for such an elaborate document. i would go either way, maybe the devs can weigh in on this.

In T2327#39453, @jessed wrote:

Also, I just noticed this on the homepage. Right front and center, bold and big in your face, is the "Bugs" image and link. I cannot, CANNOT discourage this more. The fact that users will see "Bugs" right there from the get go is going to veer away any professional seriously interested, and deter a very valuable part of the video market. Bugs present flaws, weakness, and instability. It's great that you have a link for Bug Reports under the "Get Involved" at the footer on the bottom. Awesome place for it. It's out of the way, but it lets users know that the option is there without having to navigate tediously to find it.

If Kdenlive is going to gain rapport, and subsequently greater support, and even increase the chance for greater funding, it has to have a bold, stable, reliable, functional and useful presence. "Bugs" will kill any chance of that presence in once glance -- I promise you that. The only people that won't be extremely intimidated by this are developers, testers, and techno-junkies. If this is the target audience you're trying to reach with Kdenlive, then go for it. But, please, if you're looking to appeal to any professionals, don't put "Bugs" front and center on the home page.

Alright, I'm stepping off my soap box. :) Again, it's just a strong encouragement, with motives to drive Kdenlive towards greater success. No harm intended.

@jessed and @obogdan as a free software enthusiast i see bugs as a solution not a problem. No software is perfect and the beauty of free software is to be able to fix it or at least report a bug... but i do see your point and it kind of makes sense depending on the point of view. :)

Lets focus now on the content of "Features" and "About" and we'll discuss this further eventually. It is not set in stone ;)

Thanks fot the help.

In T2327#39450, @jessed wrote:

In T2327#39365, @afarid wrote:

Now that the main structure is somewhat done I am starting to focus on content and I think we should start to focus on "Features" and then on "About".

Features

This page is to showcase Kdenlive so it should have straight to the point content and great screenshots. Have a look at some content of similar websites for to get an idea of when it is "good" and when it is "bad".

https://www.blender.org/features/
http://ardour.org/features.html
http://natron.fr/features/
https://shotcut.org/features/
http://jliljebl.github.io/flowblade/features.html
https://cinelerra-cv.org/five/Features5.pdf
http://cinelerra.org/2015/index.php/features/editing
https://inkscape.org/en/about/features/

I am thinking of first having the logos and respective links of the technologies kdenlive uses and then move on to describe the features and screenshots.

https://dev.kdenlive.org/features/

Farid, the website is looking awesome! Great start, sir! Your logo up at the top left, too.... it just works. :) It'll be great to see it become the new brand logo for Kdenlive when the time comes.

I might offer an encouragement on the features page: I would focus on the core strengths and features of Kdenlive itself before putting any affiliated technologies. If your target audience is video editors, film production studios, professionals, etc., then they're going to be interested in Kdenlive, first, and what IT can do. They need to see what makes it great. Flexible layout, advanced trim tools, timecode, multiple edits in a single project (sort of), GPU processing (once it's perfected -- HUGE feature), keyframe effects... you get the idea. I think that would have a bigger impact on viewers.

Good point, I will add the points to the list so we can further elaborate it.

Also, I'd make the logo images smaller on the other open source projects, and more uniform in size. I'd also suggest even going as far as writing a brief blurb about what the project does, why Kdenlive uses it, and a link to their website. Community, right? :)

Oh the logos are just there as a placeholder there isn't any design applied yet.

I think it's coming along very nicely. Keep up the good work, mate.

cheers

In T2327#39449, @thediveo wrote:

It's a start, but most people won't read that amount of text and start writing bug reports anyway. So, in my humble opinion, we need a short and concise intro that explains how to write a good Kdenlive(!) bug report.

All the other details are for those who want to make most of bugzilla. Most users won't bother reading all the stuff.

So it should simply say: How to write a good bug report, followed by only three or four important rules. For instance, along these lines:

• steps to reproduce: if the bug can be reproduced using only a few simple steps, this will often suffice. Please make sure that your list of steps is complete.
• minimal example: help the devs to reproduce your problem by attaching a minimal Kdenlive project. A minimal example consists only of the clips in project bin and timeline absolutely necessary. However, please don't attach video or image clips to your report unless explicitly asked to do so.
• stack trace: if Kdenlive crashes, please add a stack trace to your report. A good stack trace...

I found this link on the old website:

https://kdenlive.org/node/872

@jessed

I might offer an encouragement on the features page: I would focus on the core strengths and features of Kdenlive itself before putting any affiliated technologies. If your target audience is video editors, film production studios, professionals, etc., then they're going to be interested in Kdenlive, first, and what IT can do. They need to see what makes it great. Flexible layout, advanced trim tools, timecode, multiple edits in a single project (sort of), GPU processing (once it's perfected -- HUGE feature), keyframe effects... you get the idea. I think that would have a bigger impact on viewers.

I will put the part of technologies in the About page.

Looking great Farid, and appreciate you considering the suggestions, as always.

Just to clarify, I'm absolutely an advocate for free software too, and I think that collaboration through bug reporting is an essential component. I agree with you. I think the public absolutely needs to know it's available... just not on the home page, is all. I think where it is in the footer is a better place.. OR, even possibly make a separate page "Community", with its own link in the menu bar. All of the FLOSS stuff would fit fantastic, there, I believe.

Sorry, I know you wanted to discuss it further, later. Just thought that last bit would help.

Hey'all

I changed the homepage based on your suggestions.

https://dev.kdenlive.org/

Notice the 3 blocking tasks that we still need to address.

Cheers

PS
here is the logo (also as svg)
https://dev.kdenlive.org/logo/

@afarid , the website is looking awesome! Really appreciate you taking in the consideration to remove the big bugs button from the top. Really liking it. :)

Also, the logo is most excellent. Can't wait to see Kdenlive flashing it boldly.

One quick question: who is your target audience with the website? Who exactly are you trying to reach out to?

@jessed The audience is very generic really everything from new comers trying to discover kdenlive to old users who would go to the site to keep up with news and stuff. I am going to do a showcase section soon to show some of the latest works done by the community as well as try to give more view to a tutorials section.

Why do you ask?

@afarid, I ask because reaching a widespread audience with a generic layout and content is, egh, for lack of a better term, REALLY difficult and often ineffective, as far as my experience has seen. Currently, on first impression, it looks like Kdenlive is a piece of software, and the website is for a community of people involved with the software itself, rather than focusing more on the software itself.

While Kdenlive is the best piece of post-production video editing software for GNU/Linux to date, I don't imagine many novice or beginning users would find it very user-friendly. That's no failing on the dev's end at all -- rather, it's a novice film editor with arbitrary experience learning to use something that is more in the style of professional editing. It's the reason all of my marketing advice and suggestions have been more aimed at a professional commercial audience: they can benefit much more on this software with a much easier learning curve.

I guess I'm the advocate for appealing to professionals for two reasons: (1) There's a greater chance for it to be widely recognized as a big hitter in the video industry, and (2) they're the ones with the money. :) Everyone knows we need funds, paychecks, etc. to continue our passions (if we're lucky enough to hit a job that is in line with our greatest passions). While creating a community is great, I believe the product itself should be the main focus, not creating a community of developers and free software activists. Have a community page(s) within the website? Absolutely!! Is it necessary to Kdenlive's continued development? You bet! But if the community becomes the biggest focus, a lot of commercial users who are focused on using the program will get the feel that using the software is more for programmers or high-end techies, and they'll lose interest. I can guarantee you that.

Lightworks (http://www.lwks.com/), Adobe Premiere (https://www.adobe.com/products/premiere.html) and Final Cut Pro X (https://www.apple.com/final-cut-pro/) have it exactly right: they focus on their product in the bulk of the site, but they ALL have some kind of community link in the header bar where the user - if they feel like getting involved - can participate the community (well... with the exception of Final Cut, because they're turds like that). We don't have to re-invent the wheel, but there's a fork in the road; you can't attract everyone, effectively. Which is why I ask who your target audience is. One path leads (primarily) to open-source enthusiasts, the other leads (primarily) to big industry commercial hitters.

I have some more suggestions for the website, but I need to take the time to write it all down. My commercial work awaits. :)

I hope my posts have shown that criticism isn't my desire at all, but instead encouragements from a long-time Marketing Strategist and Filmmaker looking to take Kdenlive to the greatest feats of success possible. You all work hard on the project, and it deserves the recognition (and funding) it deserves.