Fork me on GitHub

Watch

GitHub Core

Show your support for Zikula! Sign up at Github account and watch the Core project!




GitHub Modules

Forum Activity

Forum feed

» Visit forum | » View latest posts

What are we doing wrong here?  Bottom

Go to page [-1] 1 - 2 - 3 - 4 - 5 - 6 - 7:

  • Modules Manage Content(not necessarily the core modules), and it really is a no brainer to talk about content management. If there are sub-brands, and there are in the modules, those management Icons will adorn the side of the distribution like the sponsors of a Stock Car! Not that many module developers have taken much interest in their management icon, and it is their Brand! The stock GPL icon reuse needs to be rethought in that detail. That is part of polishing and customizing, both the core, and with modules. We drive a performance vehicle with custom parts and accessories. It is time to start swapping out the mark-up parts with the rest of the performance after-market detailing, that takes our ride and makes it a hotrod.

    I think module developers should think about the marketing of their module and their brand simply in a few ways to help the overall effort, writing it down along the way. First, write down the bones of what your module does, every feature. Secondly, write down what draws you to work on it, as that is what distinguishes it. Next, write down how people use your module, take advantage of it's features, and after that how they can take better advantage of using it. Next, if it works in conjunction with other modules, write about how that works, then a little about the relationship with the other modules. At this point you write about how it functions inside Zikula, any primary features of Zikula it takes advantage of. Finally talk about how you take care of your module.

    All that might seem simple and obvious, and/or should seem obvious to the rest of us, but it is not. You manage the FAQ module, it is not about the glamor, it is about day to day tasks in the FAQ's world as a module. From all of that we will distill jet fuel. Yes, you know your module best, like no one else. This is not necessarily the modules documentation, but could form introductions to it, Because, it is about introducing your module to the rest of us as though we did not know what it is. Then bing all that material to whomever is managing the team rolling it up. Some of it will be useful for direct marketing efforts as well as the extdb.

    If each Module devs follow the example above in steps, I am sure they will have more than enough to pull a few gems out for the distribution marketing. Allow the rest of us to help too. Make the raw notes available, and let us know where they are so we can review and create a synopsis for you. It is not easy for one person to do every facet of this marketing effort, and it is not like there is a marketing department... or is there?



    Edited by TakeIT2 on Jul 03, 2010 - 01:55 PM.
  • Quote

    it is not like there is a marketing department... or is there?

    what too practical?
  • This might very well be an old thread but I think it's still a valid question.

    And yes, while development has been great, there are some key elements missing. Even if I can understand most if not all the reasons behind why this elements are missing (i.e., life outside "online", work, etc), I still cannot begin to understand why this is not something being tackled using another perspective. Here are my two cents on what would make Zikula not only good but excelent:

    Pagesetter/Pagemaster and scribite should be part of the core. Why? Let's face it, everything we do with websites is mostly list items, be it news, famous quotes, product catalogs, events, etc.: It's always a list, even when dealing with static pages. So why not make it available as a part of the core *instead* having a lot of non-standard modules? Given this, Pagesetter/Pagemaster pubtypes could be treated as modules with their own (webmaster selectable) icon on the admin panel and their own permission rules. It should be also made so that even with no custom templates, the system already has a way to deal with the items in a standard customizable way (letting you use your custom templates as an option). Themes would benefit very much from it because you would be able to create standard themes that would just work OOB with this idea. You all can appreciate the implications of giving the user base so much development flexibility! Specialized modules can and will still exist but it would make a whole lot more easy for those tech-oriented-advanced-but-non-programmers users in our community. This would also allow us to have more people designing new data-layout templates for the CMS, giving it new abilities and sharing custom solutions that would (could) become standard (i.e., making an app to produce the feed for any flash or javascript content slider, creating custom video galleries, etc) . Pagesetter.net has a good idea where things could go, with shared plugins, code snippets, and we could be adding templates, schemas and even custom solution packs.

    The next idea would depend on the prior being implemented: There should be an admin API (like what we used to have with xmlrpc) so that we would be able to manage the site's Pagesetter/Pagemaster modules enabled content from new platforms. Be it Adobe Air, custom desktop applications, Iphone/Ipad/Ipod and/or Android apps or even integration with other related/complementary software.

    The app would load the publication types schemas, build the facilities for data entry on the client side and there would be an API in place to receive the new data, putting it where it should.

    Themes should have an online template editor, perhaps all templates should.

    Modules shouldn't depend too much in whatever javascript framework you are using, we have a good example in the way the system manages block ordering, this should be the option of what's shown when Ajax is disabled.

    In keeping with the flexible nature of this proposal, the user should have a plugin for scribite editors that would allow one to connect to this Pagesetter/Pagemaster modules (publication types) as well as Mediashare. This might mean that the system has to parse inline Smarty tags that would connect directly to the publication types, allowing developers to handle media and other publication lists inline with their content putting at their client's disposal the ability to insert them while editing content (i.e. 'last x item titles from an item number y' from a publication type as a way to easily link a continued series of articles or tutorials, a 'videos tagged z' video player, a 'related pictures' slider, etc).

    The next thing would be thinking a bit about integrating heavily customized templates and rewrite rules so that one could achieve multisites or deciding the template to be used based on which publication type is being viewed using a single Zikula installation. I have achieved this in the past by templating from Pagesetter instead of Xanthia, so that the template resides inside the publication type template. Of course, this meant for me to use Pagesetter lists as blocks instead of normal blocks but allowed me to customize them easily as well. While I'm not calling for abolition to blocks, having the last request in mind, you could also be able to make use of it to create more blocks.

    There could also be a way to easily define which blocks and in which order they should appear per module and/or publication type (i.e. related videos in the video gallery, related tags for a defined search, last 'n' articles based on topic, etc) so that they only appear where the client decides to, instead of every time in every right or left column of each page.

    Some modules, like Mediashare, are more community-building oriented, so that's maybe why there was a decision to have user templates applied to some administrative screens, which is why there might be a need to expand permissions so that our community's developers are able to determine permission based templates. This way we could further customize admin templates and show our clients' communities (the client's audience) the usual template, perhaps a content uploader a less restrictive (or more admin like) template and the webmaster the full admin experience. If there's something I have heard from my clients is that they need this kind of consistency so they don't get easily lost and have to click through 3 or 4 links to get back to the admin console.

    The settings page should have a way to further define new rules for tags that should or should not be filtered (i.e., html5 tags, noscript tags, etc).

    The admin navtabs should be internationalized/translatable or however you call it. Mixed language teleworking environments make this a need.

    Having said all this, I think that such integration would allow site developers to migrate old modules' functionalities easily and scripts could be devised to handle translation of old module data into the new publication type based ones, having only to deal with things like template customizatio (i.e., remember the old Books PN module? How about pnflashgames? Legacy modules like this could be translated by using a publication type schema, giving the script a tid number and having it convert from the old module data table to the new one).

    This are not new ideas, they are also not conservative and might trample on the Zikula Roadmap, but perhaps this thoughts could give Zikula the extra oomph needed to attract more developers to our community, that is making it easier and providing ultimate flexibility while allowing us to move forward and giving a good option for those who might still need to use legacy modules by giving them the means and tools to translate their contents to a new version of the platform.

    Thanks for reading this post, cheers =)
  • While I appreciate the work done with Pagesetter/Pagemaster/Clip and Scribite, I do not agree with making them a core feature. I do run more than 130 Zikula sites today, and just 3 of them use Pagesetter, and another 5 do use Scribite. It would be a massive bloat and slow down the Core development (=ability to react to bug reports and security issues), if those big modules are part of it.
    Greetings,
    Chris

    --
    an operating system must operate
    development is life
    my repo
  • Core and Not-Core are a moot discussion. The importance of something has nothing to do with its inclusion in the core.

    think of it this way:

    A radio is a most important part of a car and is a standard install in ALL cars (to my knowledge). People rely on it. Understand its UI. Make use of it everyday. Certainly makes sense to include it in every car.

    does it make sense to say "The radio must be integrated into the engine!" (of course it doesn't). The engine and radio are entirely separate entities that perform entirely different tasks. No sensible automotive engineer would make the radio part of the engine and develop dependencies between them. Do you think you have to have your radio on a certain station to start the car? lol.

    so - this is so with PM/Clip and the 'core'. The must exist as separate entities, but eventually they will be bundled into a full package (car) that will most certainly include Clip and several other important modules.

    don't confuse 'the core' with 'the package' that will eventually be the way Zikula will be marketed and 'sold' (not really sold for $$ but you get my meaning).
  • I agree that core-notcore is not the issue. The current plan is to have a stable core and a robust collection of well-integrated options that can be added to the core (or not) in various combinations, depending on the intent of the Zikula deployer. Craig's car analogy is superb. Buy a car with a radio, with a radio with GPS, with a sunroof, with automatic or standard, with luxury seats, etc. They are all integrated in the sense that they work together, but they are not integrated in the sense of co-dependency. You shouldn't have to have a sunroof to make the radio work.

    (I suspect that we all hate the way the cable companies build useless dependencies into their product: if you want to see international soccer, you have to buy 117 unrelated channels for $$$. This is what Slam objects to. I agree with Slam. I only want to have what I need for a given site.)

    I think the core - with a wide range of options for added functionality - is exactly the right way to go. But there are a few gotchas we must continue to keep in mind:
    • The options should be as close to plug-and-play as possible. When I buy a car with added options, I don;t have to install the sunroof and wire the radio. (Unless we plan to have Zikula used only by professional coders and developers.)
    • Dependencies DO exist among the modules. This should be as close to invisible to the Zikula deployer as possible. I think we are making progress. I was testing some things in the extensions wizard yesterday and I was alerted to dependencies and given an easy way to include the necessary combinations in my package.
    • Many - probably the overwhelming majority - potential Zikula deployers are neither coders nor developers and need a simple way to get started with a collection of added modules suitable for their intent. This is what distributions are for. The concept is right and distributions exist, but they are not exactly deployed such that the newbie would easily see them. This is an area where we can make some improvements. I'd like to see a prominent link on various Z sites that says "New to Zikula? Get started here!" and that leads to a SIMPLE page that guides a first time unsophisticated user through the process of understanding Zikula, picking core and a couple modules or a pre-built distribution, and downloading-installing-configuring-adding content.
    • Power and flexibility tend to be associated with complexity, and complexity is a barrier. Every product we offer should include an 'X for dummies' type page. I am working on a collection of instructional videos aimed at the relatively unsophisticated new user and basic concepts. This has been a project on my desk for a while. Personal issues slowed me down, but part of the problem has been the moving target phenomenon. The videos I made for 0.76 were useless with 1.0. I started over with 1.1 and had to start over again with 1.2 and it appears I will have to start over with 1.3 (though I suspect that the migration from 1.2.x to 1.3 will be gradual and that the 1.2 videos will remain useful for a while).
    • Marketing matters. We have to put our product where potential customers will see it, explain simply what it does, how it does it, and WHY it is the best option. Options for doing this include teaching web skills in local community organizations, doing some simple pro bono work for community groups, writing reviews...this is probably worth a separate thread.


    Executive summary: Zikula is fantastic, the plan is good, but we need to keep the new and inexperienced user experience in mind.

    Peter

    --
    Peace
    ______________________________________
    The commonest cause of problems is solutions.
  • Quote

    This is what distributions are for. The concept is right and distributions exist, but they are not exactly deployed such that the newbie would easily see them.


    In fact, distributions are truly hidden. Back in February 2009 Simon posted a News story here about the creation of 6 distributions: Demo, Community, Blogging, Content Management, eCommerce, and Enterprise. From this story, there are links to the distributions in the extensions database, but otherwise they are not findable.

    In the Downloads -> Extensions drop down one gets links for Modules, Blocks, Themes and Plugins, but not for Distributions.

    I hope this is an oversight. I think by the time 1.3 is released (and sooner would be better) the link to distributions needs to be put back up and some work done to make sure the distributions function properly. For a while (until enough modules are ready for 1.3) it might be necessary to have 1.2.5 distributions and 1.3 distributions?

    Peter

    --
    Peace
    ______________________________________
    The commonest cause of problems is solutions.
  • I think the intention is to limit the number of distributions. probably to one. This would be in combination with a de-emphasis of the core as a standalone download. ALL the download links will eventually point to a distribution. If you want just the core you'll have to know the secret handshake. icon_razz
  • pheski

    Marketing matters. We have to put our product where potential customers will see it, explain simply what it does, how it does it, and WHY it is the best option. Options for doing this include teaching web skills in local community organizations, doing some simple pro bono work for community groups, writing reviews...this is probably worth a separate thread.


    it is worth a thread. But to get to the simple display you need the bones and meat from this exercise:

    TakeIT2


    ...Not that many module developers have taken much interest in their management icon, and it is their Brand! The stock GPL icon reuse needs to be rethought in that detail...

    I think module developers should think about the marketing of their module and their brand simply in a few ways to help the overall effort, writing it down along the way. First, write down the bones of what your module does, every feature. Secondly, write down what draws you to work on it, as that is what distinguishes it. Next, write down how people use your module, take advantage of it's features, and after that how they can take better advantage of using it. Next, if it works in conjunction with other modules, write about how that works, then a little about the relationship with the other modules. At this point you write about how it functions inside Zikula, any primary features of Zikula it takes advantage of. Finally talk about how you take care of your module.


    --
    Paul
    ____________________________________________________
    "...Humor, ITs just a state of mind"
    TakeIT2.CoM :: Open Destination
    ...my site is a perfect example of why doctors do not operate on them self :)
  • Quote

    I think the intention is to limit the number of distributions. probably to one.


    At the moment, it is limited to none.

    I don't see the value in this. Beginners should be able to quickly and easily pick a product that is suitable for their project without having to sort through a large database of options whose relative strengths and weaknesses are hard to understand until one has been using the product for a while. And those with the skill and time should be able to build a product to meet their special needs. I thought that a set of basic distributions coupled with the ability to download the core and the specific modules/themes desired would accomplish this nicely.

    I must be missing something?

    Peter

    (Coming up on 6 years here. Wow.)



    Edited by pheski on Feb 22, 2011 - 07:40 AM.

    --
    Peace
    ______________________________________
    The commonest cause of problems is solutions.

Go to page [-1] 1 - 2 - 3 - 4 - 5 - 6 - 7:

This list is based on users active over the last 60 minutes.