Rikki

In 3.x, we support HTML emails being sent by the software. However, due to constraints we had at the time, HTML emails use pretty much the same content as plain text emails, but wrapped in a simple HTML wrapper. Additionally, users had to explicitly decide whether they wanted to receive HTML or plain text emails via a preference setting - quite an anachronism. All in all, not a very satisfactory user experience. Email handling in 4.0 In 4.0, users no longer choose which type of email to receive. Our email handler sends both types in a single email, and the email client chooses the most appropriate to show based on its capabilities. If it can display a fancy HTML version, that's what they'll see by default, but plain text is used if not. Email template system In 3.x, email content is defined by the language system, and each email has one language string which forms the content for both the plain text and HTML versions. Clearly, if we were going to improve the HTML templates we ship with, this would have to change. In 4.x, each type of email has two templates - one for HTML, one for plain text. This means a better display of content can be created for HTML emails, while keeping the plain text ones simple and to the point. Email templates make use of the skinning system foundation (which we'll reveal later), meaning they have full use of logic, template tags and more - so we can also customize the emails depending on the user they are being sent to (note though that email templates are not per-skin; they are global to the site). And, of course, email templates can be added and edited via an interface in the AdminCP. This isn't groundbreaking stuff, but a vast improvement on email handling in 3.x. Email template design We also wanted to improve our email templates, so that each type of email sent was designed specifically for the purpose. The data shown in a registration email will be different to a topic digest, for example, and the email should reflect that. Coding email templates is not a trivial thing, unfortunately. The latest version of Microsoft Outlook uses the Microsoft Word rendering engine(!!), while GMail strips out all CSS included in style tags - and that's just the start of the gotchas. This makes designing email templates a tricky business, and one that requires lots of testing to ensure compatibility. For our first 10 templates alone, I reviewed 900 screenshots to spot problems. As a result, we've taken the approach of creating email templates which are simple in appearance and would work well for most sites, with the goal of hopefully avoiding the need of most sites to edit them at all (though you can, if you wish). The colors we've used are fairly neutral, for this reason. For those mail agents that are a little more... advanced, our email templates in 4.0 will be responsive. They will look great on mobile devices as well as desktop clients. I have included some examples of email templates, along with their mobile counterparts. I should note at this point that this does not reveal the main skin design. As discussed above, emails are intentionally separate in design. Admin-completed registration Friend request New personal message New profile comment

We've been hard at work on IPS 4.0 for some time now, and we're finally at a stage where we are ready to reveal the new AdminCP to you. I won't be showing you everything the ACP has to offer - some things will be revealed in more detail in later blog entries. But lets get to an overview. Background information IPS4 brings with it a new CSS framework that aims to modularize our styles. This is something we started to work towards in IPB 3.2, but at that time we couldn't completely replace our structure. We no longer have a monolithic ipb_styles.css file. We now have a bunch of small CSS files, and each one handles something in particular. There's one each for forms, tables, pagination, buttons, layout and so on. This brings a few key benefits. Firstly, when we need to make a bug fix in, say, the forms CSS file, IPS4 will still be able to automatically upgrade all the other css files for you. In 3.x, one bug fix in ipb_styles.css could mean the whole file had to be manually upgraded. Secondly, it will be a lot more obvious for skinners where to look for particular things. Need to style a button? Look like buttons.css. Easy. And thirdly, if you're building pages in IP.Content, and you want to use our button styles, you can simply include that one CSS file without needing to include the entire CSS framework. CSS is of course concatenated and compressed before being delivered to the browser, but in a development environment, it exists as I described it above. In IPS4, both front end and AdminCP share the same CSS (and Javascript) framework. Skinners will be able to ship skins that work on both the front end and AdminCP with only a little extra work - and, of course, when we make bug fixes to the framework, it'll fix both areas. Before we go further, I want to make this part clear: The front-end and AdminCP look different. What you'll see shortly isn't what the front-end looks like. We will reveal that separately later. While the same framework is used, the AdminCP extends and overrides parts of it to suit its needs and style. Goals What did we want to achieve with the AdminCP? Our current AdminCP is often regarded as the best out of the big forum software platforms, so redesigning is a big undertaking. Better user of space. Our current ACP uses vertical space for the main menu, and horizontal space for the application menu. In an era of widescreen desktops being standard, this could be improved. Get rid of dropdown menus. The main menu currently uses dropdowns for navigation, but this can be difficult to use - especially if you want access something in a 3rd party app, meaning you have to traverse the Other Apps menu. More consistency across pages. Our current ACP has some interactive tables (e.g. the member list) - but not every table makes use of the functionality. We should be enhancing every page with similar functionality, if it makes sense. Better styling. People aren't a fan of pink, it turns out. I guess it'll have to go. The blue gradients are showing their age too. And the big one: Better mobile support. You can't effectively use the AdminCP on a mobile device. It's time you were able to manage your entire community from your phone with all of the same functionality, right? Responsive by default That last one is what we're most excited about. The AdminCP in IPS4 is fully responsive, and allows you to do everything just on a phone or tablet. What is responsiveness? It means that the page automatically changes to better suit the device you're using. While a desktop user would see full navigation menus and tables of data, a mobile user will see a reduced view (but with all the same data present!). Whether you need to manage your members, change some settings, send a bulk email or run some diagnostics, it can all be done on the go. This is a first for the big community software platforms, as far as I'm aware. Preview Here is a sample page from the new AdminCP, as seen on a desktop, with the same page shown at a mobile resolution: Although I won't include it here, tablets will see an 'intermediate' view with a reduced menu on the left. So, let's go over some of the key features of the screenshots. Navigation First, and perhaps most importantly, is the navigation. On a desktop, your applications are now arranged down the left-hand side, with their respective section menus available simply by hovering on the application - no dropdown menus to traverse. The application menu can be reordered per-admin, allowing each staff member to set the menu up to best suit their role. On a mobile, there's obviously not the space for a wide navigation menu. Therefore, the application/module menu is activated by clicking the top-right icon. This opens a sidebar, from which you can navigate: Tables What you see in the screenshots are our new default way of displaying tables of data. On the desktop view, we have filters across the top, a search box (and advanced search popup), and table headers can be clicked to dynamically sort the data via ajax. On a mobile view, this all collapses down - filters and sorting become menus, while table rows collapse to show data in a more suitable view. Responsive tables are a tricky thing to do right and there's a few different approaches, but given the types of data our AdminCP tables typically show, we think this is the best approach for us. Forms As has been discussed in some of our developer blogs, the IPS 4.0 framework supports a wide range of form field types - everything from text inputs to tree selectors to matrices. All of these field types work both on desktop and with a responsive mobile view. Here's a simple AdminCP form on both desktop and mobile: Tabs Tabs are used extensively, where appropriate. Here's a screenshot showing a typical tabbed page (and it also shows a tree view): Video of the mobile view in action I've taken a short video of the member section in action, showing filtering, live searching and the advanced search popup. I'm using the iOS simulator here, which has some display jitters and requires me to use the mouse, but it should give you a good idea of how the AdminCP will work on a phone. Conclusion So there we go - an overview of the new AdminCP. We still have more to show you. Individual features and pages that are noteworthy will be blogged about in due course in more detail, so keep an eye on this blog and our developer blog for more. Please do bear in mind that this is pre-alpha software, and everything you see is subject to change. We look forward to your feedback!

Javascript is a key component of front-end web development - it's essential for a modern web app to provide a good user experience, and javascript is central to enabling that. Getting it right in 4.0 has been one of our goals from the start. Problems To begin, let's summarize some of the issues with javascript in the current 3.x series: Lack of file organization (a single JS directory that contains dozens of unrelated script files) Different script types are bundled together (interface widgets, routes and full applications all in one place) Lack of modularity (each JS file is pretty much a floating island in how it might implement functionality, with no formalized structure) Simple things requiring code (how many times have you had to write half a dozen lines of JS just to launch a popup?) New dom nodes aren't initialized automatically (load some new HTML via ajax, and your popups won't work without manually hooking them up) Resolving these problems informed the javascript framework that we've built for 4.0. It all ultimately comes down to organizing code better and making the lives of developers easier (ours and yours!). The solution Our solution has been to build a framework which is modularized and heavily event-driven. In most cases, modules never call each other directly, but instead communicate with events which may (or may not) be responded to by another module. More on this later. The framework breaks down into four types of module: Widgets - interface widgets like popups, tooltips and menus Utility modules - things like cookie handling or URL manipulation Controllers - modules which work on a particular dom node. More on these later. Models - modules which handle data. In the vast majority of cases this is simply fetching data from the server. There's also 'interfaces', which are third party scripts like CKEditor, jQuery plugins and so forth. They aren't part of the framework, so I won't discuss them here. The groundwork Before getting to specific types of modules, we needed to lay the groundwork. Javascript 4.0 is modularized, with only a single global variable (ips) being created in the page. All other scripts are defined as modules, whether they are interface widgets, utilities or anything else. A module is defined as a function which returns an object containing public methods (the revealing module pattern, if you're interested). Here's an example module: ;( function($, _, undefined){ "use strict"; ips.createModule('ips.myModule', function () { // Private methods var _privateMethod = function () { }; // Functions that become public methods var init = function () { }, publicMethod = function () { }; // Expose public methods return { init: init, publicMethod: publicMethod } }); }(jQuery, _)); This pattern works well for our purpose, because it enables a module to contain private methods for doing internal work, while exposing only those methods which should be public to the outside world. This example module could then be used like so: ips.myModule.publicMethod(); So this keeps everything neatly organized, and ensures variables don't leak into the global scope (which we want to avoid at all costs). When the document is ready, the module is automatically initialized (though you can also have functions that execute before DOMReady if necessary). Interface widgets It's fair to say that interface widgets make up a large proportion of the JS used in our software - a web app such as ours has an intrinsic need for popups, menus, tooltips and so on. As mentioned above though, the big hinderance in 3.x is that these widgets have to be created manually (or, in a few simple cases, a special classname is added to an element to initialize it). This feels unnecessary when all the developer wants to do is show a simple widget that is otherwise standard. To alleviate this hassle, interface widgets in 4.0 all support a data API. What this means is that any widget can be created simply by adding some parameters to an HTML element, and specifying some options. Need a dialog box that loads a remote page? Simply do: <a href='...' data-ipsDialog data-ipsDialog-title='My dialog' data-ipsDialog-url='http://...'>Click me to open a dialog</a> Or if you need a hovercard, just do: <a href='...' data-ipsHover>This will launch a hovercard</a> We already have around two dozen widgets built, covering everything from dialogs, menus and tooltips, to keyboard navigation, tab bars and autocomplete - all supporting initialization with data attributes. Building your own widgets is easy - they are built as a module, and then simply define some settings to be accepted. The widget module does the rest. They can either be initialized when they're first seen in the dom (which you'd want for something like an image slider widget), or when an event occurs (such as hovering on a link, in the case of hovercards). Whenever new content is loaded into the page, widgets will be found and initialized automatically, too. Most widgets emit events when certain things occur - when we get to Controllers, you'll see why that is useful. Utilities Utilities are simple modules that don't need much discussion. They simply provide methods which do something useful - for example, fetch/set a cookie, write to the user's local browser database, or handle timestamps. Controllers Controllers are the meat of the application. Whereas interface widgets are used (and reused) as dumb tools on a page, controllers provide the logic for particular elements, sections and pages. They would, for example, handle the interactions in the topic listing, or the interactions with a post. Notice the word interaction - controllers are specifically designed to deal with events on the page. In fact, that's almost all they do! Controllers are initialized by specifying the controller name on an element, like so: <div id='topic_list' data-controller='forums.topicList'> </div> This div becomes the controller's scope. The controller can manipulate content inside the div, watch for events, and so on. Controllers, in general, should be as specific and succinct - so simply specifying a page-wide controller then handling everything inside it is discouraged. If we take the topic list in forum view as an example: <div id='topic_list' data-controller='forums.topicList'> <ul> <li data-controller='forums.topicRow'> ... </li> <li data-controller='forums.topicRow'> ... </li> <li data-controller='forums.topicRow'> ... </li> </ul> </div> Each topic row might specify the forums.topicRow controller which handles locking, pinning, or marking that topic. The topic list itself might specify the forums.topicList controller, which handles sorting and loading more topics. By doing it this way, controllers become responsible only for a specific portion of the functionality, which keeps them lean and simple. Controllers are entirely decoupled and cannot reference each other - which is by design, given that a controller is only interested and responsible for its own scope. To communicate, events are used. A controller can trigger events on the page, which other controllers, widgets and models might respond to (and in turn emit their own events). Continuing the example above, let's assume one of our topic rows is being deleted. The forums.topicRow controller handles removing the HTML from the DOM, but it doesn't care what happens after that - it's not its responsibility. However, it emits a deletedTopic event to let the page know. The forums.topicList controller sees this event, and because it does care, it loads a new topic entry into the list. By using events like this, we can build interfaces that respond fluidly to user interactions while still maintaining separation of concerns. So, how does a controller deal with events? Because we're using jQuery, event handling in controllers piggy-backs with the on and trigger methods. In the controller's initialize method (which is specifically for setting up event handlers), you simply do: this.on( 'menuItemSelected', '#menuid', this.handleMenuClick ); Usually when setting up events in an object using jQuery, you need to use $.proxy to properly control the scope of this, but in controllers, this is handled for you automatically - you just specify the method name. Notice the event we're observing here - menuItemSelected. This is an event that the ui.menu widget emits, and it illustrates how widgets and controllers can interact. Controllers can watch for events from widgets, then do something with the information given, all without ever directly referring to each other. Triggering an event is similar: this.trigger( 'doSomething', { color: 'yellow', size: 'big' }); This is the same syntax as jQuery's own trigger, except that the controller will ensure the parameters object is passed between different event handlers in the same chain. This will hopefully be clearer when you get your hands on it. Models Models are quite similar to controllers (they also use the special on and trigger methods), but their only purpose is to handle data. By decoupling data handling from controllers, we can centralize data getting/setting so that any controller can use it. Let's say we have a user model, which handles data for the current user. It might have event handlers for adding a friend, for example, so when it sees the event addFriend, it handles it appropriately. Let's also assume we have a controller on each post in a topic, there's three posts, and that the controllers are observing the click event on the 'add friend' button. Here's the sequence of events: (controller1) click 'add friend button' (controller1) emit 'addFriend' event (user model) adds a friend via ajax (user model) emits 'addedFriend' event (controller1) updates friend icon (controller2) updates friend icon (controller3) updates friend icon Even though it was controller1 that requested that the model adds a friend, all controllers respond to the event the model emits and updates the friend icon in its own post. This again shows the power of using events as the primary communication system - anyone can respond, and the caller doesn't have to deal with maintaining associations. Conclusion So that's about it - the new JS framework in IPS4. Hopefully this in-depth post has covered everything you need to know at this stage. You'll be pleased to know that most of the framework and widgets are already documented, and that will be available when IPS4 hits beta. Do note that everything covered here is subject to change or removal, as usual in our development blogs. If you have any questions, feel free to ask!

I'd like to introduce two new areas we've been working on. These new areas are designed to support our developer community, while making it easier for our clients to get their custom projects taken care of. Projects http://community.invisionpower.com/resources/projects The first new area is Projects. When you have a custom project for which you need a developer/designer, this new area will allow you to gather responses from developers interested in working with you. Post your project details, choose an approximate budget and date, if applicable, and developers can then register their interest in the project. From there, you can contact developers to help you decide which to go with. Projects you post will be open for responses for 30 days, after which they'll be closed. If you agree to work with a developer before that time, you can mark it as completed by clicking the Accept link next to the chosen developer's response. You'll be notified when new developers respond to your project, too. IPS won't be involved in the communication between you and a developer in any way, so it's up to you to agree project details and exchange payment, if necessary, before work starts. We hope this will become a handy tool to help match up customers and developers on custom projects. In time we'll add more features, such as the ability to review customers/developers when a project is complete. Developer Profiles http://community.invisionpower.com/resources/developers The second new area is Developer Profiles. This new area gives developers a place to present themselves to potential customers. When a developer creates a profile, we'll automatically build a page for them that pulls in their Marketplace information, and gives them a way of highlighting one of their contributed files and a place to write about themselves. As a customer, you can browse the listings to check out the developers in our community. If you've worked with a developer or just like their files, you can Recommend them by clicking the link on their page. If a developer with a profile responds to a Project, we'll link their name to their developer profile so that you can find out more about them. We hope these two new features will help foster more growth in the development community, making it easier for customers to find developers, and giving developers a central place to find potential work. Check them out - and if you have any feedback, please do feel free to share it. We've already made many changes based on the feedback from our preview to developers, so now it's your turn :smile:

As part of our goal to improve the usability of IP.Content, particularly for non-coder administrators, we've used the 2.3 release to look at ways of reducing or eliminating the amount of code that needs to be written in order to create great websites. In the current version of IP.Content, blocks require individual templates (entered as part of the wizard process), and the default, unedited HTML is generic and not ideal for most blocks you'd want to create. This clearly left room for improvement, so we're pleased to introduce our solution: block templates. Block templates give us two primary benefits: Make it easier for IP.Content users to set up a good website, without needing to code Make it possible for those who can code to share interesting block interfaces either directly or through the IPS Marketplace Reusable Block Templates In IP.Content 2.3, the templates that feed blocks use are created separately, using a new Block Template manager, and then assigned to blocks when they are created: The block template manager What does this mean in practice? Firstly, it means that block templates can be used by more than one block, without recoding them, and when changes are made to the template, all blocks update at once. More importantly, it means block templates can be created, exported, shared and imported, so that those with the skills to create them can share them with those who can't. We hope this will spur some great block interfaces from our modding community, to benefit all IP.Content users. How does it work? Templates are linked to a feed type and a content type. For example, you might create a template designed for "Topics" in the "Forums" feeds, or "Albums" in "Gallery". In addition, you can create generic templates based on a content type alone, for example "Comments", which can then be used with any feed that shows comments. Adding a new block template When feed blocks are created, you are presented with a gallery of all suitable templates. Clicking one previews the template with the real data that the block will generate, so you can see exactly what the block will look like on your pages: Creating a new feed block using a block template Of course, if you still wish to provide a custom template for a particular block, you can do so - the process will be exactly the same as before. A Javascript & CSS framework provided To go with block templates, we've created a mini Javascript and CSS framework. This means that all block templates, whether they are provided by us or by our modification community, can maintain a consistent style. The required framework files are automatically injected into all IP.Content pages, whether you use the IP.Board wrapper or your own HTML wrapper. The javascript side of things is powered by jQuery, and based on the jQuery UI Widget Factory. Block templates can include their own assets, such as javascript widgets, CSS files and images. IP.Content automatically compresses all the JS and CSS files from all templates into a single minified file to help keep websites loading quickly and cut down on HTTP requests. Sharing templates As mentioned above, block templates can be exported and shared with other IP.Content users. To make this process very simple, when a template is exported, it's built as an XMLArchive - that means all of your CSS, JS and other assets are compiled into one file for you to distribute (a little like an IP.Board skin is). Exporting a block template into one XML file Conclusion To give you a taste of what is possible with block templates, here's a demo page I've created using some of the default templates we'll be providing. No code - other that putting template tags into a page and adding a div to make the right column - was typed to build this page! An example page using default templates Our aim with block templates is to allow all IP.Content administrators to have interesting, useful, interactive blocks, without needing to write the code themselves. The addition of a new standardized JS and CSS framework also means that blocks can maintain consistent styling, regardless of who authored the template. We'll be including a number of pre-made templates with IP.Content 2.3, and hope that the modification community and other coders will embrace the new possibilities offered by block templates, and create many more to be shared via the IPS Marketplace. Once IP.Content 2.3 is released, we'll publish some developer documentation to help you get started with the new tools. We think block templates are a huge step forward in making it easier to create websites using IP.Content. We hope you exploit their full potential! We look forward to your suggestions and ideas for improving the software in our feedback forum. We heavily rely on feedback from all of our clients to shape the future of our software, and even if we don't reply to every topic, rest assured they are all read. If you have any comments on the new block templates feature in IP.Content 2.3, please share your thoughts below!

We've had specific support for mobile touch devices in the IP.Board suite for a number of versions - these devices see a specially designed skin which is stripped down and touch friendly, rather than the usual skin. We've taken the opportunity to update this skin for IP.Board 3.2, refreshing some aspects of the style and adding support for new features. Launcher Gone is the linear menu of community links, replaced instead with a new launcher screen that shows the various areas that can be accessed: As well as looking more pleasant, the increased space for each item should make tapping easier. In addition, you'll notice that we now display bubbles that show the message/notification counts, like on the default skin. General interface improvements We've restyled most elements in the skin, to lighten it and reduce the space necessary. As an example, here's the topic list: You'll notice the navigation bar that used to be present is now displayed as a 'Back' link in the header bar - a convention mobile users are well used to. The individual page title is shown in the black bar, with the page content following. In this particular screenshot, you might also notice that we're using the standard default skin read/unread topic markers, since they're perfectly suited. Here's a look at the slightly-updated topic view: As well as the cleaner display, you might notice we also support the new Like feature for posts. Notifications Notifications aren't something we've supported in the mobile skin before, but with more focus being placed on them in IP.Board as a whole, we took the step of adding them to the mobile view too. They essentially work just like you're used to, with the option to go to the user, the content, of the individual post: Tagging Tagging is a new feature introduced in IP.Board 3.2, and since tags can be set as required when posted, it was essential that posting support was added to the mobile skin. This series of screenshots shows the process: To remove a tag, simply tap it, then tap the Remove Selected button that will appear: If you choose to use the closed tagging system (whereby users can only choose from tags you define), a select list is shown instead, allowing users to choose from the native phone interface. View New Content/Searching IP.Board 3.2 introduces a new way of filtering results when using View New Content or when searching. A bar is shown on the left, with the various filter choices able to toggled on and off to change the results. While this interface clearly wouldn't work on a mobile device, we did want to ensure the filtering options were still available. This is what we came up with: Clicking one of the buttons on the top bar presents the available filters, with the currently-used shown with a check:

Back in February, we posted a series of blog entries about improvements to our Calendar application (part 1 2 3 4 5). To go along with these technical changes and improvements, we've completely overhauled the calendar interface to modernize it and improve usability. This blog entry will review those changes so you know what you can expect when IP.Board 3.2 is available. Main Calendar View When first visiting the calendar, you're presented with a refreshed calendar view. The main calendar now takes up the full width of the page, since it's the most important content on the page. Mini calendars now appear below - available, but not hogging space. The new filter bar above the calendar allows you to switch seamlessly between month, week and day view. The menu next to the page title allows you to switch the calendar you're currently viewing. Week View Week view hasn't changed substantially, but does continue the filter bar and mini calendar styling introduced on the main page. In both the month and week views, you can double click a date as a quick shortcut to viewing that day. Day View Day view presents a much cleaner overview of events and birthdays taking place. In addition, a quick overview of members who have RSVP'd to an event are shown. Event View The redesigned event view shows full information about the event, together with comments and the RSVP list. We hope these improvements to the Calendar application go down well with your community, and spark more use by members! The new interface together with new features and improvements have given the Calendar a completely fresh feel, and we hope you like it!

In this entry, I'll be showing the new streamlined Sign In and Registration process in IP.Board 3.2. Registration in particular is a key interface in any community. Too complex, and users will be put off signing up and taking part, potentially costing your community dearly. We've known for some time that our current registration process has needed streamlining to improve user conversions, and IP.Board 3.2 has proven the ideal time to implement the changes. Step by Step Our registration routine (when IP.Nexus is used) is unusual in that it behaves as both a store and a sign up process (to enable users to select a subscription). While not everyone uses IP.Nexus, it's important for us to consider this aspect and find a suitable solution regardless of the products used. To solve that, we've changed the registration routine to be a clear step-by-step process. First, a subscription is chosen if available. Next, account details are entered. Finally, the user gets confirmation. A step-by-step interface gives users clear expectations of the process they're about to follow, which is great for usability. Reducing clutter and confusion The current registration routine involves a number of disparate steps, collecting information that doesn't warrant an entire screen individually. This simply puts obstacles in the way of users trying to join. The account details step now consists of just one screen. COPPA, terms and conditions and of course account information is all covered on the one screen. COPPA, if enabled, appears as a modal popup. Instead of asking users to select their birthday (used only to verify they were older than 13), we now just ask the simple question: "Are you over 13?". Easy. Once they confirm, the popup is dismissed instantly, and the form is ready for them to begin. The registration form now consists of just 4 fields (6 if you use the Q&A and ReCaptcha features). So what's changed? Display Name - we no longer show the display name field upon registration. Requiring users to choose two names invites confusion, and the difference is not apparent until the user is familiar with the community. But fear not, the display name feature hasn't disappeared. Instead, we set the display name to be the same as the log in name during registration, but users are free to change their display name later in their UserCP. Confirm Email - There's no need to confirm the email address field. It's plain text, and many users simply copy and paste the first field anyway, duplicating rather than fixing an error. Time Zone - Having the user choose their timezone simply adds to the burden of registering. Instead, we now try and determine their timezone automatically behind the scenes, and it can always be changed in the UserCP. Another change is that the community terms and conditions are no longer presented on an entire screen. While important, they again present a roadblock to getting a user registered. Instead, they're now shown in an inline popup, and the user simply checks a checkbox to signify their agreement. Custom profile fields set to 'show on registration' also appear on this page as usual. However, we urge you to consider whether a particular field is essential at registration! More fields equals more work for users, so the fewer the better! Inline Sign In Something that has been requested for some time is inline sign in, and I'm pleased to say it's now available in 3.2. To simplify the process, users signing in with 3rd party systems such as OpenID will still be required to use the full sign in page. In our experience, though, the vast majority of users use the default IP.Board sign in, and the new inline popup should make the process a little easier for them. We hope you find the changes give a boost to your community when IP.Board 3.2 is available. By streamlining registration and sign in, we hope to encourage your guests to convert to members and contribute to your community.

We've gradually been revealing aspects of the new IP.Board 3.2 front-end interface, and naturally there's much more to come. In this entry I'd like to preview the new interface for the Search, View New Content and User Content views, since all three of these views essentially share the same interface elements. We previously covered the changes and improvements to View New Content, and these changes have been incorporated into the new interface. As always, please note that screenshots are from development software, and are subject to change before the final release. Overview The biggest change is of course a brand new filter menu, to replace the myriad dropdown menus that we currently use. Content can be effortlessly filtered with single clicks - whether it's changing the app you're searching, the sub-section, or the time frame. Search sorting In addition to the main filter menu, search results also make use of a new filter bar to enable sorting and ordering (again replacing dropdown menus). This is an interface concept that you can expect to see more of in IP.Board 3.2. Language Non-English users will be pleased to know that we're now making use of IPSLib::getAppTitle() for tabs and titles in the search interfaces, so that the correct translation is always displayed. We hope you like this brief preview of the new search interface! The changes we've shown here and elsewhere are a taste of the improvements we're making across the product to improve usability and aesthetics. There's plenty more to come, in our blog entries and public previews. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

While we aren't quite ready to show off IP.Board 3.2.0 in its entirety yet, I wanted to talk a little about what you can expect from our new front-end skin - our thinking behind development, areas we've focused on, etc. Goals Before development commenced, we created a list of goals that we aimed to meet. These include: Improving the experience We've been accused in the past of having a 'clunky' experience in some areas, so we've worked hard to improve the user experience in key areas. Some of these are usability changes, while others relate to reducing clutter on the screen or relocating elements. Making the skin easier for 3rd party developers (and ourselves!) to use Another focus was on making our skin - particularly the CSS - easier to use, for skinners, developers, even our own team. We've found that as new features were added, whole blocks of existing CSS were copied, pasted, then tweaked to suit the new feature. This creates some resource overhead, not to mention more work for skinners and developers. To remedy this, we've begun introducing a new approach to our CSS: more modular units that can be reused and combined easily to make many interfaces easy to implement. This will be gradually introduced throughout the skin as areas get updated in future point releases. Already, we've been able to remove large sections of old CSS as the updated areas make use of the new modular CSS. Modernizing the display It's been 3 years since we first began working on IP.Board 3.0, and the internet has come some way since then. We decided it was time to refresh the visual style of our default skin. While it will still be clearly recognizable as IP.Board, we've added some polish to the overall style, and made more use of technologies such as CSS3. Areas that we've focused on A huge number of areas have had minor tweaks here and there, too numerous to list here. But other areas have had significant updates, including: Global wrapper This is probably a given, since it influences the rest of the skin. Parts have been made more streamlined, with a new member & moderator bar, a new application bar that now supports as many apps as you choose to install, inline sign in and more. Forum view While the basic concept of listing topics inside a forum hasn't been altered, we've made big updates to the presentation, including rethinking the display of non-essential items and a new, friendly topic preview. Topics view As with forum view, the basic structure has not changed (familiarity is a good thing!), but numerous elements have been tweaked, changed, and tidied. All in all, reading topics should be a more pleasant experience for your users. Profile Our profile view was in need of overhauling, so that's what we've done! It now sports a vastly cleaner display while keeping all the relevant information accessible. Data from 3rd party apps is easily incorporated without fear of breaking the tab bar as in 3.0. In addition, we have merged profile comments and status updates, giving members a modern 'wall' in their profile. Calendar We've previously posted blog entries about new features you can expect to see in Calendar, and to go along with that, we've completely revamped almost every aspect of the calendar display - hopefully making it a more inviting place for your community to share events. Registration We identified some time ago that our registration routine was less than optimal, especially when considering communities that make use of IP.Nexus, with its ability to sell packages at registration. To remedy that, we have rethought the registration routine, to present Nexus packages in a better way, get rid of unnecessary steps along the way, and above all make it quicker for your prospective members to register Moderation We will elaborate on this point at a later date, but we have made the various day-to-day moderation tasks easy to access and use - a boon for your moderating team. View New Content Our View New Content area has steadily grown more complex as additional sorting and filtering options have been introduced, so we felt it was time to improve the display of those options to make it all a bit easier to use. Posting Screen We've updated the new topic/reply screen to be more streamlined, as well as integrate some new goodies that we'll talk about later. Redirect Screens The old-fashioned 'you are being redirected' screens are now a thing of the past. Every area has been updated to use a new inline notification display, which doesn't get in the way and fades after a few seconds. Teasers To whet your appetite, here's some teaser shots of the new front-end. We'll be gradually showing more as we discuss new features in later blog entries. While these are just teaser shots, over the next few weeks we will start posting blog entries about new features on the front end that will also contain screenshots of new skin elements so keep an eye on our blog for more updates! Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

One of the areas we identified as requiring significant update in IP.Board 3.2.0 was the member management process. Member management is, for most communities, the most frequently-executed task that happens in the AdminCP, so it is important the process is quick and easy. In previous 3.x releases, each different type of member (normal, banned, validating etc.) had a separate page from which you could manage that type. Once on the correct page, you check the members you want to work with, then select an action. Refresh, repeat. In IP.Board 3.2.0, we've significantly streamlined the entire process. All types of members are now viewed in a single interface, though that interface can adapt depending on what you're viewing. Let's take a look... Viewing Members Notice at top-left a toggle bar, to change the member type you're viewing. Notice also that the column headers (member name and email, in this case) allow for sorting. All of this takes place dynamically - virtually no page loads are required for any action in the new Member Management section. Searching for Members Searching for members is easy - simply start typing in the filter box, and results are displayed live in the list. For more specific searching, you can use advanced search to narrow your criteria. Managing Members Managing members is a one-click process. The available options for each member are presented as buttons; clicking an action confirms it and removes that member from the list. Previously, you would have to (in this example) select the members to ban, scroll down, choose the appropriate action, the page would reload, then you'd have to do the same for the members you wanted to delete. In IP.Board 3.2, you can simply work your way down the list, choosing the appropriate option for each user. We expect this will be particularly useful when managing validating members. Once you've cleared the list, the page will automatically load in another 20 members for you to manage. You can still mass-manage members, however. Selecting some members enables the available mass-actions, and again, once you confirm, more members are loaded for you automatically. Summary Member Management is now essentially a one-click process - a vast improvement on previous version of IP.Board. We hope that the new process will significantly reduce the time you spend on the repetitive and time-consuming task of managing your member base. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

One of the primary areas we have targeted for improvement in IP.Board 3.2 is a fresh style and usability improvements for the AdminCP. Our AdminCP has long been considered one of the best in the industry, so while we didn't want to tear up that work and start again, we did feel it was time to make substantial improvements. Overview First, let's take a look at a general overview of the new style: As you can see, we've tidied up the header area. The live ACP search, which has been a hit feature, has been made more prominent (more on that later). The 'button bar' that many pages make use of has been styled more like a toolbar in a traditional application. Many other general aspects have been tweaked, such as improved typography, removing various bits of clutter on the screen and updating the drag handle to the standard used in places like GMail. Sidebar / Menu In 3.0/3.1, the sidebar is the primary way of navigating through an application. The downside of this is if I'm in the Forums app and I want to, for example, edit a member, I first have to click the Members app, then find the item in the sidebar, and finally arrive at the page I wanted. We felt for an app of the size of IP.Board, more effective navigation could be done by using multi-level dropdown menus: This makes it really speedy to get wherever you need to get. You can even navigate to your non-core applications: The sidebar can be hidden, giving you more space on your screen for the important content. I've been using the new menu system for weeks, and I certainly couldn't imagine going back to using the sidebar as the primary navigation method. I hope this makes routine administration tasks noticeably easier for everyone. New Item Menus In 3.0, item rows that have additional options are displayed using the icon. While this works fine (especially when there's many options), it could be made quicker if the primary actions were buttons in their own right. IP.Content and IP.Nexus have had the new item menus for some time, but they're now used throughout IP.Board. Primary actions (such as Edit and Delete) are displayed as buttons, while less-frequently used options remain in a dropdown menu. The row you are hovering on highlights itself for easy identification: (Fun fact: this menu system is generated entirely with CSS3 - so it's incredibly easy for mod authors to reuse) New Tab Bar In IP.Board, many sections use tab bars for situations where you can edit all of your applications at once (for example, the Tools & Settings section). However, problems arise when you install lots of extra applications - the tabs can spill out of the bar and break the page layout. To resolve this, we have added a new style of tab bar, that comfortably displays as many apps as necessary. By default, it looks like a standard tab bar: But when many apps are installed and your browser window is not large enough to display them all, it adds smooth scrolling controls: New Form Style Though not a major change, we have updated forms throughout the ACP to use a slightly different layout. In 3.0, field descriptions were displayed under the field title. Where fields had long descriptions, this was unwieldy, and contributes to making forms more difficult to use than they should be. In 3.2, we have updated the styling so that field descriptions appear directly under the field they relate to. Field titles meanwhile are right-aligned, making it really easy for your eye to travel the page and identify items: New Live Search I mentioned earlier that the ACP live search had been made more prominent in the interface. We hadn't expected it to be quite as popular as it is, so in 3.2, we've improved the display of the results box. Often, a search would have dozens of results, which made them difficult to scan through to find the relevant one. Live search in 3.2 breaks down the display into sections, like so: Summary We hope that the new navigation system and live search really makes finding what you need highly efficient, so you can get on with doing the important tasks. We hope the cosmetic and usability tweaks makes performing those tasks just a little bit easier. And, of course, we hope you like the overall styling we are going for. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

Note: Since this entry was published, our Resources area has been updated with the new version. Go there now to see these features live! One of the main aims for IP.Downloads 2.3 was to overhaul the interface to bring it up to scratch. To that end, we have focused on 3 major areas in this revision, which we'd like to show you now. File Submission The current submission screen in IP.Downloads became unwieldy as multiple options and configurations appeared in each release. We've redesigned the upload process from scratch, to properly guide the user through each step and put the files they're uploading at the center of what they're doing. The new screen is composed of three steps: files, screenshots and information. It's displayed as an accordion so the user can focus on one thing at a time: The next step is to add screenshots to the entry: Notice here that the first screenshot is highlighted; this is the new Primary Screenshot feature covered in yesterday's blog entry, allowing you to set the 'main' screenshot for a file. To do so here, you simply click it to highlight it. Finally, you add metadata... File View Next we updated the view file page. Notice the primary screenshot is shown prominently next to the description, whereas other screenshots are available below. IP.Downloads Portal The final screen isn't so much an overhaul as a brand new page altogether. We felt one of the areas that could be improved in IP.Downloads is being presented with interesting downloads right on the front page, rather than a clinical list of categories. To achieve that, we've updated the homepage to be a portal of content, like so: Three main panels appear on the homepage: what's new, highest rated files, and most watched files. Each panel shows up to 18 files in a scrollable pane so it's easy for users to browse. In the sidebar, we show top downloads and top authors. Note that if you have the IP.Nexus/IP.Downloads integration enabled, instead of seeing Top Downloads, you'll see Top Free Files and Top Paid Files. Also when the integration is enabled, files will display their price: We hope you enjoy what's coming in IP.Downloads 2.3, and we'd love to hear your feedback!

We are pleased to announce that IP.Gallery 3.1.0 is now in the beta testing stage, and has been installed on this board for public testing! This update brings many refinements, performance optimizations, and new features, including: Friendly URLs IP.Gallery now makes full use of the IP.Board FURL system. Categories, albums, images and more now have the friendly URL structure you're familiar with. Image notes Image owners are now able to add notes to sections of their images, positioning and resizing them to suit. Other members will be able to see the notes when hovering over the image. (An example) Image rotation Images can now be rotated in 90