After Daniel outlined the basic models that will be used in the profile pages for the Connection Engine I drew up some rough wireframes. The first is a basic user profile page for an individual. The aim is to mesh contact information and the challenges the individual is putting into the system.
The second is a profile view for a news organization. Similar to the user view this would bring together contact information as well as support history for the news organization as a whole.
Any feedback, critiques, or ideas are completely welcome.
As I mentioned yesterday, the first set of models I’m working on are for the People and Organization applications. I’m going to outline them here so that Andrew can put together basic wireframes for how the information will be structured on the view. We’re going for a basic profile view where the contact information is one part and the activity stream is the other part.
I’m adding the type of field the data is for the edit view. Users will be able to edit their own profiles and the organization profiles they are the administrator for. CoPress admins will be able to edit any profile and any organization profile.
People – Profile model extends the Django User model and includes:
- First name (text field)
- Last name (text field)
- Date created
- Position (text field)
- Organization (foreign key to an existing organization within the system)
- Phone (dropdown with multiple options and ability to add multiple phone numbers)
- Email (dropdown with multiple options and ability to add multiple phone numbers)
- IM (dropdown with multiple options and ability to add multiple phone numbers)
- Websites (dropdown with multiple options and ability to add multiple phone numbers)
- Address/Location (multiple text fields)
- Photo (uploaded file
- Bio (multi-line text field)
Organization model includes:
- Name
- Date created
- Slug (unique)
- Summary (multi-line text field
- Websites (same as People profile
- Email (ditto)
- Phone (ditto)
- Address
- Photo
The organization view will also have a list of staff depending on which users in the system have the organization in their profile. The user’s position and photo in the staff view will be pulled from their personal profile. Lastly, every object in the system will have the ability to be tagged with various topics. Clicking on fields like Location and Position will produce a filter view where you can see all of the People or Organizations with that piece of metadata.
We’ve let our advisory board lapse somewhat and I think it’s wise to put that together again with the hope of actually getting their feedback on big milestones (most notably the re-relaunch of the hosting and support program).
I did a bit of research last week on what startups normally do with their advisory boards. Fortunately, OnStartups Answers has a few really valuable threads on this topic. Basically, there are two directions we can go. One is to recruit a board of advisers that is volunteer, not necessarily required to respond to queries, and that we talk to occasionally. Two is to recruit a board of advisers that we compensate in some form and have a more formal relationship with. After talking this through a bit, it makes more sense to go with the former with where we are currently. Albert made a good point that if we are depending on the advice and input of any one person heavily, it would probably just make more sense to hire them as a consultant.
I see the steps as:
- Email the people we want to have as our advisers and see if they’re interested
- Put together a Google Group or some sort of mailing list for conversations
- Encourage them to subscribe to this blog and send the bigger things we want input on to the list serv
Related, there’s a really good interview with Giacomo Guilizzoni, founder of Balsamiq, that a couple of threads pointed to:
We don’t have any formal agreement nor do we meet regularly. Mostly I email them whenever I have a question I know they’ll be able to the answer, to or we meet on Skype once in a while (we try to shoot for once a month but somehow haven’t been able to keep a regular schedule with anyone. Things get in the way.) We all got together for a big crab-dinner feast in San Francisco in May, something I hope to turn into a yearly tradition.
It’s pretty informal, but every time I have some sort of contact with one of my advisers, I learn something. Or they say something that gives me an idea, or gets me unstuck. That’s what talking to smart people will do. I always say that one could do a lot worse than trying to be excellent, because “excellence attracts excellence”, and when you’re in that circle, even once in a while, magic happens.
He’s got an example letter for when we want to put together an advisory board page. I’m also very interested in his approach to transparency on the company blog, and want to reopen the discussion on how transparency applies to us in the form of a blog post when I have the time to put it together.
Just a brief update from me right now. I may write more later if I have more time to work on it. Basically, what I’ve been doing for some amount of time today is trying to abstract the first level of functionality we want for the Connection Engine into different applications, and then defining the models for each application. Here’s what I’m thinking for the base level of functionality:
- Challenge and Solution – In some senses, this is the support ticketing mechanism. I want to move away from the support ticketing paradigm and instead focus on having well defined “Challenges” leading into documentation of the steps to produce a “Solution.” Once the Challenge reaches the Solution stage, then the tread is closed. A user can spin off a new Challenge from a closed one, however, that will create a relationship between the two.
- Profiles for People and Organizations – I’d like to duplicate a lot of the base-level functionality that Highrise offers us currently such that we can tie it closer to the Challenge and Solution functionality.
- Invoice and finance management – Basic accounting software that ties into the Profiles application and builds upon what Albert is already working on.
I’m focusing on the Profiles first, and it’s actually going to be two applications initially: People and Organizations. My goal is to define the models for the first, get them to validate, and then build the models for the second. Once I progress further on that, I’m going to start on HTML mockups that will provide a foundation for starting to work on the logic.
With this post, I also want to articulate a couple of issues worth solving at some point with this application. Well, couple of issues that are different sites of the same bigger one of communication. It’s about documenting the work that’s being done with any given project in such a fashion that both the person doing the work and the client have a really good sense of what’s going on. Having an experience for this will allow the client to submit a Challenge/support ticket, see that we’ve opened it and are working on it, read through the work we’ve done to resolve it, and then reference it later if they have an additional question about it. I think a highly-structured work log as a part of the Challenge to Solution process will be very important as we scale the number of projects we’re working on and need to have memory of what was done when for when the inevitable questions about it come later.
So… I think we need to have stronger branding for the new hosting program when we roll it out in a couple of weeks. Internally, we’ve been calling the first two versions Hosting v1 and Managed Hosting, but I don’t think that CoPress Basic vs. CoPress Standard is much better. Basic and Standard don’t communicate the services very well. Unlike Basecamp, we need to have our names communicate the services, or at least be more distinct, because they aren’t necessarily different tiers of one product. They’re different tiers of multiple services tied together. Does that make sense? Any ideas?
Hometown News Service is a hosted content management system for small to medium local newspapers. They have an application into the Knight News Challenge as well where they want $250,000 funding to continue developing their CMS, make it easy to deploy, and then open source it. They have 75 paying clients right now and 12 employees so I’m not entirely sure how this fits into their strategic goals.
Asked a couple of days ago. This is exactly the type of bridges we want to be making because we are hosting campus magazines too that probably have really valuable advice. One big question is how you make these bridges more intuitive; right now it requires one of us knowing the right person to connect the asker to and shooting them an email. Related to this, I think it might be wise to start thinking about a good taxonomy for Highrise. It will be a system we have to maintain but we can quickly find the right person by topic.
I’m headed to West Palm Beach, Florida on Monday for a week to hang out with DJ Strouse and Casey Stark while building cool things with Django, aka work on the Connection Engine. Casey put together a project blog and I’ll probably post updates there, here, on the blog, and on my own blog. To start things off, however, I gave them a short introduction to the ideas behind the Connection Engine.
One of the time-consuming parts of an archive transfer currently occurs when we migrate a database with a large number of authors and attempt to add each author as a user. Personally, this is my preference because it means we keep the integrity of the data as true as possible (the other option is to assign the post to the default user and then store the author data as a custom field). The import slows down, however, as the number of users in the database increases largely, I think, because WordPress isn’t optimized to handle a large number of users, let alone content from a large number of users.
As such, I think it might be worthwhile to make it standard operating procedure to import authors as custom fields and then have a secondary script that checks the custom field for author information and then creates the user if the author doesn’t exist or assigns the post to the author if the user does exist.
Related to the time required to migrate archives, I wonder if we should go back to importing the content directly into the database and bypassing the creation of WordPress eXtended RSS files. If we did this, we could likely automate more of the process. Thoughts?
We should see if we can get in on their webinar. I’m going to shoot them an email.
Recent Comments