pisaldi

I have (relatively) big plans for calendar in 3.2. We can't really say too much yet, but I promise - you will see improvements to calendar in 3.2 (not just a few small bug fixes or tweaks).

just create the team_icons folders in each of your /public/style_images/*skin name* directories and use {style_images_url}/team_icons/*icon name*.gif for the url to the group icon image.

Would be great if this could happen

Unfortunately team icons are board based and not skin based - crazy isn't it?

If you install some nice team icons, they show up in all of your installed skins, but they may not match the appearance of all those skins.

Imagine some nice Christmas skin themed team icons looking rather odd when viewed by someone who is using a non-Christmas skin, or white/bright team icons from a white/bright skin showing up automatically on a black skin.

So my suggestion is to make team icons a folder in the skin images. :rolleyes:

I'm proablly one of a few users out there that would still like to see IP Nexus or something similar to make an appearance, i can think of so many uses for it (having my own store), and plus it would cut down on costs for using other software.

Any thoughts? (even though it proablly won't happen lol) :hmm:

Yeah, there's only 3 people that would look at the thing, right.
Again, nobody is talking about a 300 page manual here, and nobody is talking about having to print the thing out. A properly indexed, categorized and written manual can be done as a webpage, or countless other ways. Articles are NOT manuals, they are articles, wordy, opinionated, and don't provide a bit of guidance.

As far as your "examples", yes, F1 help IS as close to a manual as you're going to get, but guess what? Even that is properly categorized, appendicized and developed. The user can quite simply search for the right thing, and it's there, which is more than can be said for this product right now.

The point is that the product needs this. It's big enough that there is a problem if you don't tell a user how to do something, not in an "article", but an actual manual. By not having something like this available, it wastes current, and new customer's time, and certainly doesn't promote customer satisfaction in the least.

Sure, if you want to keep the same customers that don't care about proper documentation, don't put out a manual. Doesn't matter to me any more, as I'm already done wasting my time on a poorly documented program.

You know Tom, I don't know where this mythical documentation for every product in existence you refer to is. You refer to every product you have including a manual, yet... well, lots of software doesn't. I'll do a quick inventory of a sampling of my start menu now (I'll include the OS itself even). I'm excluding "F1 Help" since that's essentially inline help.

Microsoft Windows - No Manual.
Google Chrome - No Manual.
Microsoft Office - No Manual.
Microsoft Visual Studio - No Manual.
MYOB Accounting - Quick Start Guide.
Beyond Compare - No Manual.
Apple iTunes - No Manual.
Kayako SupportSuite - Manual Available!
Microsoft SQL Server - No Manual.
Seapine Surround SCM/Testtrack Pro - Manual Installed!
Stardock Multiplicity - No Manual.

As you can see, lots of stuff with no manual. And you're also completely ignoring what they've said many times - that the majority of their customers prefer articles, guides, inline help, etc over the three hundred page book they printed last time. It doesn't make commercial sense to write an entire manual for three people.

I have, multiple times. How many times do I have to say it? Look at the competition, look at their documentation, that is a perfect example of a well written, proper documentation manual, and it's not hard to keep up to date. It's a win/win situation.




I'm not going to continue to log helpdesk request after helpdesk request with garbage such as "how do I do this". That wastes MY time and your time.
Inline help does not do that, yet, and it shouldn't ever.
A "quick start guide" doesn't do that now and shouldn't ever do that
Articles are entirely too wordy for that, and entirely too opinion based.
A flat out manual, properly indexed, properly updated would resolve this.

Since IPB doesn't want to do this (will not) , there's really no further need for discussion. I'm sorry that you can't see the need for it, but that's your problem not mine.
When it comes down to it, the excuses from IPS and IPB have turned me away from the product itself. As I stated in my blog, I'm thankful it was only a $20 investment, because it certainly was a loss, but I'm not going to continue to waste my time trying to figure out where things are at, or how to do this, all because someone doesn't want to write proper documentation.

While I sympathize with your position, this line really doesn't work.
Sure, documentation doesn't "write itself", but then again, neither does code. As this stuff is written, it should be documented, not as an afterthought.



so, which is it? Will there be a manual, or will there not be a manual? Please, do clarify.

The types of documentation described previously work somewhat well (though articles are not documentation by any means) for new users, yet these do not relieve the need for a manual of some kind.

Getting started guides, great idea, and could easily be a 'chapter' in the manual, but definitely don't take the place of it.
Inline help, as well, great idea, but this doesn't cover everything at all, and it shouldn't.
Articles, too wordy and opinion based, definitely not documentation.

There needs to be some sort of manual here, which, as already said before (not by me, mind you) would cut down on needs for support , and promote some sort of customer satisfaction. Somewhere a customer can go and say "ahah, THIS is how I do this", whether it's an advanced customer wanting to learn how to change a theme, or a new customer just wanting a step by step guide to creating a new forum. Both of those are just examples, but you still have a major need for documentation here , because the product obviously does not document itself.

Developers are not left to themselves. In fact, we have more developer documentation at this time than anything else. :blink:

http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&category=135

I have to agree with the OP here... Everything in life comes with a set of instructions, IPB should be no different.

If you educate people properly about your product then you should reduce some of the strain on your support system, you will also reduce the amount of frustrated customers who post there questions here and never get a reply. If you put the hard work in at the start, it will pay off in the future giving you more resources to build more products to make more money... see where i'm going here?

To use the excuse "we have more developer documentation at this time than anything else." is just lame IMO. It goes to show that you didn't do the job properly first time round.

That is not documentation by any means.
Documentation helps the user understand what they're doing (and yes, even developers need that at times), not simply throwing them into code.
Documentation belongs in a manual, well written, well thought out, well presented, not spread out over 50 different articles.
In addition, it's on the company to provide documentation, not the end user.
Articles are opinion based and wordy, documentation is not.

You want to see proper, broken down documentation? Look at your competition. THEY did it right, and they've managed to keep it updated well enough. Examples, and explanation of what should be done, not just random code left for the user to figure out for themselves. Not to mention they've managed to keep it up to date. Easy to read, very well outlined, easy to follow manual.

Allthough there's the helpfiles we can alter, it would be nice if the board holds a FAQ feature. In there admins can add whatever FAQ they want, regardless whether its about forum or there surrounding websites and features.
My users come with so many questions that if I was to put them into helpfiles, the list would be so enormous that it would be unattractive to use. Besides that, the Helpfiles do not show in language bits so I would have to create helpfiles for all languages on my board, making the list twice or three times as large.

It could be done in a forum layout I suppose, but it would be nice if there could be a way of just listing the questions (categorized) making it easy to find the right question, clicking on it and getting the answer.

If someone allready created anything like it, I would be very interested in finding out how you created it (using IPB off course)

Elanor

Brandon, et al

I would have to disagree that "most" communities don't use a calendar - consider that folks, like me, can't use the calendar because it does not have enough functionality.

I work with a few hundred chapters who use systems like Meetup or Calendar.net in addition to their forum systems because they can handle events by state, sub-state (chapter, region, etc.), handle mapping, geolocation, RSVP, etc. They have members cross country (and around the globe) who have, on average, 4 member events per month - and post many more in support of other chapters and organizations.

Meetup.com - community with calendar - is nirvana for me but too locale specific. Joomla with jCal is as close as I can get to the "perfect" CMS integrated calendar - but it lacks RSVP [and commercial development, roadmap, consistent support, etc.] which is a non-starter for me.

Look at nearly every CMS forum and you will see RSVP as a feature request.

For me Calendar features are the difference between IPB and vB - so far you are winning as you have a start date/time and event type, on the fence because I can't see where calendar entries can be linked to forum posts - so at the very least it's opportunity for solid differentiation between vendors working with "communities" of users.

Sometimes communities meet... a calendar is a key component of that, IMHO.

Regards,
gp

At this point, profile fields are not listed in translation menu. I guess that's because board admins can alter and add as much as they like. In the front end of the board however, this means that people choose a language, but when entering a profile, everything is in english (and there are many people in this world that do not speak english well enough to understand everything).

Off course Board Admins can translate these fields into the native language of their board, but then English people using the english language will be confronted with that native language. Translating therefor is only an option if you translate a board in your native language and only use one language throughout the entire board.

There is an option to add new profile fields, but that means new columns in database will be created, because one part uses english profile fields to enter data and the other users de fields of other languages. This makes it difficult to query data, cause same type data is spread in the database over various columns.

Then there is the possibility of altering the profile fields zo contents will be in both languages. That's an option for boards with few languages, but with more than 2 languages, profile field names will contain so much text that filling in a profile is not appealing to new users.

It would be nice if this important part of forums (after all it all starts with registration and creating a profile) would be in the translation bits.
It can start out with the primary profile fields, with the contents in english, that come with the installation. When translating through ACP it at least minimizes the need for entering custom profile fields with same data as the ones in english. That would allready be a big help for many I guess.

But above that it would be great if a feature was created that offered "instant" translation options when adding a custom profile field, like when you create a new custom profile field, you do so in default language, but after creating, you'll be offered a screen saying:
"You've added a custom profile field. We've located # other languages on your board, please fill in the language bits for each language" offering a list of boardlanguages, with empty strings for each profile field entry, (like in translation part of ACP). In that case adding a field means you add it in all available languages.
Don't know if thats possible, but I guess it would be a wonderfull solution for all foreign customers with a multi-language board. If this feature should be created, I'll do my part by translating the default profile fields in my native language, dutch.

Perhaps others, reading this topic, can give their opinion about this suggestion, maybe even improve the suggestion with other, more usefull ideas.


Elanor

IPB Staff, i have had my ticket open for 20 hours.. and not a single reply , all i want is 2.3.X Converters with instructions...i need them asap , but been waiting for 20 hours..

Any quick response is greatly appreciated .
Thank you guys.

If this has been asked before then ummm.. Oops.

Anyway... It would be nice if fixes made were to be documented as part of a fix in the bug tracker. I'm not talking about complex fixes, but more of simple or of elevated severity/importance.

If it's a small typo in the php code or if it's something else that only takes a couple of minutes to do, then it'd be nice to know so that members can apply the fix themselves.

If it's got a more than average severity level, that fix would be appreciated as well, at least if it's something that is severe because of the amount of functionality it affects, etc. I know that security issues are always made available via announcements, so that's not really a concern (kudos to IPS for always making those available in a very timely fashion).

Obviously if it gets complex, requiring an edit in multiple files, SQL queries, etc, then it's best for us to just wait as the instructions would take up quite a bit of time to include. But simple fixes could help us not only do minor 'upgrades' while we wait for the next release, but also if that bug fix causes another issue or isn't working quite the way it's supposed to, then it can be addressed again and another attempt made before the next release.

I'm also not talking about nightly releases or anything. Just something we we customers can do fixes to our installs if we want (and we could even pick and choose the fixes to install until the next release). When a fix isn't made available, something that explains what was happening or what was changed would be nice to.

Sometimes a fix or an explanation is included and that's very much appreciated, as it's usually done in a way that helps us to understand (in concept at least) what was wrong and what was done to correct it. Just would be nice if this was done more as a standard.

Just in case there's any misunderstanding, I'm not dogging on IPS in any way. Just that I noticed a bug in which the fix was included and it was nice to see it. I know that it'd be next to impossible to do it for every single bug reported, but if it's a simple enough fix (and I do mean simple) or if it's an important enough fix, just be nice to be able to apply it without having to wait. Obviously, all bugs reported and fixed up to this point should just be left as is. Just some feedback as 'food for thought'.

Hi!

I manage a multilanguage board...

What I need to know in each upgrade, is ALL the changes that has been done in ALL upgrades...

What I mean is you give us a list indicating for example:

System --> public_search --> actperiod_week (first page)
System --> public_search --> actperiod_today (first page)
System --> public_search --> actperiod_month (first page)
System --> public_search --> actperiod_weeks (first page)
System --> public_search --> actperiod_year (first page)

and so on...

This would be very useful for updating our translated languages...


This would be fantastic if you make in future updates...



Thanks in Advance

Hi!

I manage a multilanguage board...

What I need to know in each upgrade, is ALL the changes that has been done in ALL upgrades...

What I mean is you give us a list indicating for example:

System --> public_search --> actperiod_week (first page)
System --> public_search --> actperiod_today (first page)
System --> public_search --> actperiod_month (first page)
System --> public_search --> actperiod_weeks (first page)
System --> public_search --> actperiod_year (first page)

and so on...

This would be very useful for updating our translated languages...


This would be fantastic if you make in future updates...



Thanks in Advance

I run a large sports forum and we rely on the games to generate traffic. My suggestion is that the calendar be made able to add dates from an outside source. The sports teams release the schedules in formats such as Microsoft outlook calendar files and csv. files. Is it possible to add this function of auto import?

Your lucky your post is not on my board and you need to take lessons on how to be nice to people.

Lindy, what about something where the user can check off a list of things that match their problem..


Please choose from the list what best matches the issue you are having. ( ) Is your board offline, inaccessible or giving errors? ( ) Are you having a problem getting into the AdminCP? ( ) Has your board been hacked, attacked or in some other way compromised? ( ) etc ( ) None of the above. Picking the wrong item from the list can cause delays in your ticket. If you are unsure of what to pick, then pick none of the above.

A few like there where the person can choose what best matches their problem (similar to the list you have but could be after they have submitted the ticket the first time and before the final submit. "None of the above" could be pre-selected and would cover things like low priority items. Obviously it's hard to cover all high priority items, but if there are 3 for high priority that are generic enough to cover a wide range (but specific enough to eliminate false positives) then that could potentially help prioritize some of the tickets.

Obviously the ones marked "None" might benefit from a fast review by a staff member to see if it's a high priority so it can be bumped up in importance, while leaving the rest of the tickets alone, but no system is perfect.

Hope something in this post is of some use, be nice if it helped to improve the ticket times, even if only a little bit. I've generally never needed to submit a ticket for problems on my boards before, but I can imagine how the customer must feel when it is an important issue and every minute seems like forever.

If there are going to be more services added, then something like $20/year (or $25/year if it must be more than $20/year) as an add-on license would seem reasonable. It could offered and available for every non Standard IP.Board license that the person has (so if they have 2 Lifetime licenses, they'd purchase 2 of the add-on licenses).

That argument is on pretty shaky ground. You might, in that case, start charging extra for FURLs, AJAX skins, or any other progression in the software... as far as I'm concerned, my license entitles me to use IPB and it's features in all future versions, forever... You're moving the goal posts in order to sheppard legacy customers into your newer pricing bracket...

... and yes, I do pay my annual support fee already.

No, and I do appreciate that. I should've mentioned that in my post - I think everyone would have been more upset if there had been absolutely no avenue to move aside from purchasing a whole new licence!

I like the security that my perpetual gives me. I know that's kind of ironic as I bought a perpetual instead of a yearly licence and IPS could've folded a year in and I'd have lost money (but thankfully, that didn't happen!), but I like the fact that I can log in at any time, no matter what my current financial state is (which is currently dire - thanks recession) and I am always able to upgrade my software so that my board is as secure as it can possibly be.

I understand that the spam service is a subscription type service, so once your support ended, so would the service? So I understand that if my financial situation decreased further and I was unable to renew the service, it would leave me open to being unprotected by the service - but I do see the spam service as an added benefit and therefore, not quite as important as having access to the latest software.

I'm not sure I'm saying it clearly (I've had a very long day, sorry) but if push came to shove, I would hold the software in higher regard than the extra services - so risking my access to the software in return for the services concerns me. I know I'm looking on the bleak side - as it shouldn't be a risk, and it'd be great if I could be completely sure that I could afford the service renewal year in, year out - but just in case I can't, it would worry me to move.

From another slightly pessimistic point of view, what if I don't get on with the service? In that scenario, I will have given up my already-paid-for updates to the software for a few months with a service that I would no longer use.

I will think on, but those are my knee-jerk concerns. :)