Comment to 'Want to learn about your use cases of running a community management system'
Comment to Want to learn about your use cases of running a community management system

  • This is a great discussion to start. UNA is indeed quite powerful and can be used in various way, but it is really important to develop vision and structure before turning things on and off. We see that at least half of the projects end up getting lost in unending feature-juggling, instead of costing on a couple of core use-cases and building community culture. 

    Set constrains!

    I can't stress it enough - define what you want to build BEFORE you turn on features. For example, if you're building something like Twitter (microblogging network) - you don't need to enable Albums, Discussions, Events, Groups, etc. Just use Timeline, Updates or Posts for main content items, Channels, Persons and Messenger. Turn off friendships, relationships, don't use paid levels, don't set up Spaces, etc. Then, clean up navigation and all forms to ensure there's nothing there you don't need. Keep it simple, try to make it work with bare minimum combination of modules. Onboard test users, start growing your community, get to the first 10K users or so, talk to them and you'd know if there's a calling for, say, Groups or maybe dedicated Videos section, etc. 

    Launch early 

    Often people "build" for years and never launch. It gets worse if the first advice is not followed, too. You learn far more about your site needs when it has real users. Nothing like production run. All the today's giants started as small and simple sites - it's OK. Launch when you have an MVP and iterate!

    Ands as for UNA - it can be used for many things, but we do have our goals set out for education, collaboration, creative content sharing and eventually distributed personal social networking. 

    • T

      Thank you for replying first, Andrew. You know, I am strongly committed to the vision of the UNA developper team.

      What I learned so far, after approx. one year digging into community platform design (you are the architects, we are the designers) is, that whenever I am in online conferences with people I just learn to know, my mind starts flying around "what's her goals and how could she profit as my community platform member". I know, it's useless, but I cannot help it.

      I found out, that the most demanding thing for me as a UNA community plattform designer, is assuming what's the best tools for my future community members to use, especially with potentially "concurring" modules/tools. For instance, I could eather use Groups mod for people with some kind of matching interests, or I could offer them the new Spaces mod, which could mean by far more options or, in a negative way, overwhelming my community members with too much functionality, when they just try to gather as a group with the same interest(s). Other examples are Discussions vs. Articles vs. Feed contribution (I know the difference, but you need to explain it to your community members first, in order to understand its usage) or E-Mail Messages vs. Text Chat, etc. I am sure, for you inventors of the UNA platform and for the majority of us, who dig into the world of the UNA CMS, concepts are clear. But, sometimes, even I get lost with concepts. Remember the Video Webinar, when you explained the new paid join and I watched the recording, and got lost in the difference between admin rights and group admin rights.

      I would like to stress out your statement about too much functionality, that might people discourage from using a community platform. Keep it as simple as possible and give them tools they like to use.

      • It's important to remember that UNA modules are not always complimentary. Many of them overlap in functionality and sometimes should not be used side by side at all. For example, Albums, Photos and Videos - you only use Albums for Facebook-style erosional mixed-media albums, while Photos are more for sites like Instagram, and Videos are for sites like Youtube. Albums contain photos and video files, but grouped, so they can't be browsed as a separate media types. It owed be way too confusing to use all 3 on ones site, especially if there's no clearly articulated purpose difference for each.