I have worked with several CMS systems and I am not understanding the logic that Invision has decided to use in building Nexus...Maybe they could be more clear with videos or better documentation, but for the newbie or first time Nexus user, there is very little intuitiveness about Nexus.

First the distinction of the CMS vs Nexus is sort of blurred here as Nexus has "Pages & Menu Management > Page Management > Manage Pages & Directories" and the CMS has "Dynamic Content > Articles Manager > Manage Articles > Manage Article Groups". How or why should they be different. Are they not both dealing with Articles to be posted or viewed? It was my understanding that IP.Dynamic (the highly touted CMS) was scrapped and its functions were to be placed in Nexus and then a separate application of CMS was born... that is just the start of the confusion.

BTW what is the point of the CMS being a "plugin module" if you have to go to "Tools & Settings > System Settings > View all Settings | Content Management Tab " and add in information for static pages....oh it seems to think it is still IP.Dynamic according to some of the references in there.

Now for a simple example, or what should be simple, the ability to change polls or add a poll to a page.
The client side shows you


Wait, I am logged in, shouldn't I see a poll??? Can't find a setting in Nexus, but Launching the CMS portion now yields an interface for this, but how intuitive is that? Not very.
It says

What does that mean...oh wait there is a cute little magnifying glass there, click that...okay now I see
Click to view attachment

hmm thats what I see on the client side, but where or how do you place this code or even find the page it would be on and I have yet to see 'Insert IPD...' in any page editor. Here is an example (hmm more IP.Dynamic references) where is the 'Insert IPD..." at ?? Closest I see is "Insert Special Item" and there is nothing about polls or bits there.
Click to view attachment

It seems to me that Invision has Envisioned a new way of doing things and really needs to bring its documentation way up as well as explanations, other wise I don't see this being very competitive among other CMSs that are FAR more intuitive. From what I see I don't even get how they can call this a Beta product....Beta is supposed to be final trials of 90% or better code for release and what I see was just a quick over view in less than 20min of working with it. So with so many parts missing in just a small portion how is this a beta?

My apologies if the staff things I am shot gunning some bad PR, but the fact is, IF IT IS not simple to operate and you must read a 408pg manual (not created yet) it won't be very popular, except among hobbiest and I really thought Invision was trying to move more towards business or am I wrong?

My suggestion is get some documentation going quickly as well as some charts on work flow or even video support so we can learn your ideas and how you are thinking so we can all be on the same page.

Thanks for accepting my input.

It takes some getting used to.

When I first saw IP. Nexus I didn't like the way things worked, but after using it for a little while, you can at least get used to the system. Although there should be some docs, but I'm sure there will be.

The difference between Manage Pages and Manage Articles is Pages are static, Articles are dynamic.

Thank you for your feedback. It should be noted that IP.Nexus is still in beta testing and is not the final, finished product that will be for sale.



This is a bug, obviously.



This is a bug which has since been fixed.



This is also a bug. It should read 'Insert IP.N Tag...' from the page editor. This refers to the text editor. If you click 'Insert Special..' you'll get a drop down. I'll revise the text to make this more clear.



Documentation is currently being written and will be available for when IP.Nexus goes on sale.

Please keep in mind that you're getting an early preview of Nexus without any documentation, etc so it's bound to be a little confusing initially.

Matt I really appreciate the personal reply. I mean no disrespect, I have become quite fond of the IPS company, I just expected that Beta4 should have more polished pieces to it for this release.

Thanks for continuing to earn my respect, it is greatly appreciated!

Keep up the great work and CONGRATS to you and the Mrs. on baby Mecham.

Thanks, William.

Thank you for taking the time to articulate feedback, William. I would like to reiterate what Matt said and assure you that I am actively working on IP.Nexus Documentation, and it is an ongoing process. If you have any suggestions in regards to IP.Nexus Documentation (e.g. layout, formatting, etc.), please feel free to let me know, as I'm all ears.

After playing with the interface, I'll have to agree with the initial post in this string. The interface is quite confusing in Beta 5 even. I don't even understand how to:

Create an article template
Frame in content blocks, menus, ads, etc.
Use this template to insert content

Also, I don't think there is a way to preview the articles in the system. I really like to see this feature added.

excellent comments. i thought all of the same things.

I don't know to much about editing the templates in IP.NEXUS maybe if you could try and give some more idea on how to change the css and what not ???

I am so glad others are experiencing these issues....I really expected better by the latest RC now.

The CMS area of Nexus is one area we will be working on improving the usability.

I hope nobody gets mad at me for gravedigging.

However I must agree. While this is a beta, the...friendliness of the interface is quite low. I see this as software with potential, as we can all agree it's going to be powerful. But after searching through I did not know how to change the domain name that my site uses. I was in a rush and my domain didn't have the nameservers propagated yet, so I used the IP address instead when installing. However I searched through to try to change it (when domain did propagate) and failed to find that setting. I had to manually edit the PHP file.

As for the addon components I am clueless as to how to find them. I currently have no idea how to access the Customer Support module to submit a ticket. I don't know if it's something I'm missing or perhaps I just didn't search hard enough, and I consider myself to be decently web-savvy (having admin'd several IPB boards and owned my own) in regards to IPB products.

And the CMS addon I find kind of confusing as well. It would be nice if the index page could be integrated into the CMS instead of it being a HTML page.

The only way to change the domain (to my knowledge) is by changing conf_global.php - it's the same with IPB.



I'm not positive what you are referring to. Do you mean from the front end or the back end? Was the customer support application installed? You can check that under the Nexus tab -> Applications & Modules. If it is installed, on the admin side you click the "Launch" button at the top and choose "Customer Support". From the front end, you login to the "Client area" and then you can submit a ticket.



The problem with this, as I understand, is that not everyone will purchase or install the CMS. We can't, thus, make the default upon installation reliant upon the CMS being present, because in some/many cases it will not be.

My bad, I was thinking of the upload URL and image URL (Tools & Settings -> General Configuration in IPB 2.3)


The front end. I don't see a "Launch" button. But if you mean My Applications, yeah I see it and can choose it.
For the front end I'm logged in and click Client Area...but I see nothing related to the support area.


Would it be possible to add it as an option to the CMS system? Like allow the CMS to make changes to the core components to allow the CMS to run as the front page and stuff.

Woah! Stop the press... Most of what I've read around here and the old site has been extreme interest in the CMS and integration of current IPS products.

What is the default application being based on then? The CMS should be the most robust or excited addon to the Nexus IMO. Seriously how many people are interested in the hosting module compared to the CMS module?

Don't misunderstand me and think that I'm trying to add bad PR, but honestly I don't think Nexus will survive relying on a hosting solution addon only. Infact, if you don't add better "user friendly" " to the backend & promote more the "CMS of Nexus I feel it's price might eventually be forced to a lesser price of the IP.Blog system or even scrapped.

If you need a manual to even work the basics of the system then something is really wrong and off especially for those of us used to IPS styling. At the very least the backend basics should be very obvious and they are not even for the experienced. I'm almost blushed to say but icons grouping the settings would be a plus right now ie. Articles, Plugins, Frontpage, Themes and etc.

I made a suggestion feature in another topic and was told it would be complicated because people wanting hosting solutions wouldn't have a need for such thing? The suggestion was for a module/plugin to diverse the use, but it's clearly apparent that Nexus is and only will be a "hosting/billing" solution and that CMS type ideas are the least concerns right now?

My main client base is lawfirms, e-commerce, pay-to-access, subscription based and hobbyist of which I have never had anyone expressed interest in a hosting solution to be honest. I would have to retract my statement in another post about purchasing Nexus regardless because we are basically being clearly told right now that Nexus is not for me and everyone right? I know this has been said many times even with loyal clients opposing the idea of such but just to confirm this is the clear intent correct and that Nexus is only being designed with the Hosting/Billing genre in mind and the additional modules available might find use for them just to perk up their sites?

@bfarber - This post is not directed at you - I'm only commenting on general replies throughout the forum.

In the end I just have to say *Sigh*

Firstly, before replying to too much, we entirely expect that people will be completely changing the 'Default Site' that is shown when you first install Nexus. What is there upon installation is ONLY meant to (1) have a basic site when you install the software rather than an error screen of some sort, and (2) give you a loose understanding from where the current data is how to add your own data (i.e. adding new pages, or editing the menus).



For upload url it's Nexus tab -> Tools & Settings -> System Settings -> Server Environment



To be honest, I'm not all that familiar with the front end. On my installation I found that the query string has to be

&appcomponent=core&module=customer_area&section=tickets

I believe, similar to the CMS, there can be no guarantee that a user has PURCHASED the customer support module (or whichever module includes this functionality) so the links are not generated by default for it. i.e. if you wanted a link to submit a ticket, you could add one in your page somewhere, or add it to one of the two default menus (or if you scrap the default menus and make your own, add the link to your own menu).

See, again, you have to remember we entirely expect that whatever is there during a default installation (1) cannot rely on modules which may or may not be purchased, and (2) is going to be changed by the user. This is not IPB. With IPB, users do commonly use the default skin. With Nexus, there is no skin - you are building a site, and what is there is not what you would go live with.



I'm unsure - something Josh would have to address. I'll point him to this topic. Again, though, this is entirely possible for you to do. We realize there is no documentation right now, but that will indeed change.




For YOU the most important application might be CMS, but there are tons of people that are largely interested in the billing application. With Nexus, either or both or neither could be installed. You can't build the entire application assuming the CMS will always be there. There have been dozens of topics in this forum during the beta testing period alone where a user has said they were interested in application x, with x not being the CMS.

The default application is the "core". You could theoretically get the core with no applications, and it would run just like it does during an installation now (if you did not check any applications during the installation). The core itself supports adding html pages (which is what powers the "default site"), the menu system, settings, user management, and so on.



Stop getting caught up on the hosting module. It is indeed unlikely many will purchase just the hosting module. It is conceivable however that a user may purchase the support and billing modules, and have no need for the CMS (perhaps they already have an HTML site they are satisfied with and do not want to deal with a CMS to manage it, but want a fully featured store to sell their products). Again, the point is, you can't RELY on the CMS module being installed.

I will concede that personally, I believe it will be the most popular, mind you. I'm just saying, we can't code the front default page to be dependent on the CMS module - then anyone that installs the application but doesn't have the CMS module will receive errors upon installation.



1) We will have documentation available. Someone is already working on it.
2) This is a very very powerful system with a LOT of features. I'm sorry, but you can't honestly expect to understand a system of this nature out of the box just by intuitiveness (if that's a word). Nevertheless, there is an "Interface feedback" topic pinned in this forum already where we've asked people to tell us what needs to be changed to make the system easier to understand and easier to use. If you think something is difficult, just saying this is hard to use doesn't really help much. If you say you think link x should be made on page y because the items are related and it would make it clearer what one thing is doing to another thing, that can be taken into account and changes made. This is a beta, and a lot of the effort right now on Rikki's part is going into purely updating the interface to make things easier to use and easier to understand. He needs appropriate feedback to do so.



I'm not sure what suggestion you are talking about. Adding a module I'd think would be independent of anything else...so I'm not sure why adding a module would be difficult based on someone having the hosting module. Can you clarify or provide a link, as I'm sure I'm not understanding this in context.



No, your statement is not correct. Nexus is NOT being geared only towards hosting and billing. It is also NOT being geared ONLY towards users who need a CMS. It can do all of this, or none of this. In order to understand the focus you have to step back for a minute from what YOUR uses are and understand other users have other uses, thus we are attempting to make the software general enough so that users with other uses are covered too.

However, if you ONLY need the CMS, it is quite capable of using only the CMS. The resources site, outside of the download manager which was ported over to work in Nexus, is by and large ONLY the CMS. We don't use billing or hosting there. It's a great example of things that can be done with just the CMS, in fact. Articles, homepage, rss imports and exports, the links module (which is actually just a touched up version of articles) - all of that is based out of the CMS application, combined with "core" functionality.

After you log in to the client area, you should see a link called "Your Tickets" which is where you can submit support reuqests.



I'm not quite sure what you mean here, allow the CMS to change the core components in what way? A basic CMS is included with the Core Nexus install, you can see it in the "Pages & Menu Management" section of IP.Nexus. Essentially the entire front end of Nexus is powered by a basic CMS, buying the Dynamic application extends this with much more advanced CMS functionality.

Brandon, that was a very long and very well thought out response to several people and nice poke at my word "intuitiveness", however it is worded, this project is not straight forward at least from the responses I have read.

When this was born it was a CMS system, how it got dumped and a hosting system took it over and then the CMS became an add on module is BEYOND me and apparently many others here as well. For well over 2 years we had been hearing of a CMS system, wanted one, got feed back and expected one.

For you or any other staff member to suggest that it is separate and at an additional cost AND requires the hosting module for it to run, has many feeling very let down by IPS. Quite frankly it has a great number of us running off to products such as SubDreamer, Joomla, Mambo or any other host listed at cmsmatrix.org. Many which are STRAIGHT FORWARD in their "intuitiveness".

You guys want feed back, here it is, make the CMS module a PART of the Hosting system. This is what many wanted and were looking for, another great product by IPS. What we have now is a several deep beta modules of which confuses every one as to how they work, which part does what, what part takes over the functions of another when installed and no CLEAR map as to what each module is or how it should even function. Mostly we know it is confusing and there is very little to no information on how it works in parts or wholly as a system.

It seems to me that there should have been a preliminary users guide of functions with mock up screen shots and listing of features that you guys must have had at your meetings to develop from. If you do clean that up with the current beta info, screen shots, etc... and put that out for us to reference from. However it seems to me that this doesn't exist and its not clear from many answers the features, the interlocking, interwoven parts should be or function together.

How about releasing more demos (like that hasn't been asked for before) of how each part should work and how the parts work together. Also demos about how to change the look of a site, if indeed the host part can do this, as well as the CMS skinning process. Oh and from my tests, it would be very nice to see the database updated with each module added so that when you want to include a 'plugin' or 'function' in your site its as simple as a drop down selection instead of knowing where to go look for the code or how to construct code to do so.

This entire project reminds me of Zen Cart, Works great for the users from their perspective, but from the admin side, not very fun to plug away at.

So in conclusion, more documentation and supporting demos to view.

Thanks
Will

Nexus does not require that the hosting application be installed, it doesn't require that the billing application be installed, it doesn't require that the CMS application be installed, it doesn't require that the downloads application be installed, etc. The whole point of the system is to let you pick and choose the parts that you need. If you're a hosting company with a website in place, buy the Hosting app and not the CMS app. If you are not a hosting company, or selling anything, then only buy the CMS application and not the Billing or Hosting application.

IP.Nexus is a framework that allows you to mix and match all of the applications that it supports. You can read this for more information: http://forums.invisionpower.com/blog/ips_n...?showentry=2097

I think you are severely mistaken about Nexus.



Firstly, let me say, I wasn't poking at the word. I didn't realize/had forgetten you used it. I was using it myself, but wasn't sure it was a word, so I added my little statement. Nothing personal.



A hosting system did not take this over. Nexus core is basically member management and a very primitive basic CMS and that is it. Nothing more, and nothing else required.

What happened was we had Nexus going and Dynamic going at the same time, using nearly identical code in many places, but because the applications were separate there were a lot of conflicting areas as well. Users were not registered to both at the same time. You had to manage the look and feel of the areas separately (they were separate applications, after all). And so on.

We decided rather than maintain two very large code bases, most of the code doing very similar things, and fight this uphill to merge the products.

If you wanted Dynamic, you would purchase Nexus core (which has NO hosting functionality at all) and the CMS module. This is basically what used to be Dynamic and does not have any billing or hosting functionality. It does have all of the previous functionality Dynamic used to have. Thus, we did not forget that there will be customers purely looking for a CMS who do not want any of the other things.



Well, why would it be PART of a hosting system. They do work in parallel just fine (i.e. our site) but they are two different functions. And there will be a LOT of customers (i.e. China J above) who have no use for hosting.

Admittedly, there is little information and documentation - please appreciate that we realize this and do have documentation in the works. It has been started, there is information being added, and not by developers either (so hopefully people can read it as we tend to go off on tangents when explaining things lol).

What would really help is knowing where the confusion lies exactly. Every module is independent of every other module, but at the same time they are all plugins to one larger application. Just like each section of your site is a plugin to your site as a whole. If you want one part, you purchase/enable it. If you don't want it, you don't. Where are things breaking down (outside of not understanding what a feature does or how to use it, though we do need that information too)? That's what would really help improve things.



There are always internal feature lists, but I don't have access to any for Nexus. Screenshots will be included in the documentation (again, in the works).



Demos will almost certainly be forthcoming as well (have you seen the others posted to our blog?) however Rikki has been spending a lot of his time trying to clean up various parts of the interface to work better together. Right now this is a beta, remember - most of the developer effort is going towards working on the product. We have someone separately working on documentation in parallel to this, and I imagine demos and explanations of various individual features will come after the fact.

After all, if we make a video demo of something and then entirely change the layout and look of the page, that video demo isn't really relevant any more. It wouldn't be the best use of our time to be redoing these over and over at this stage just yet.



I don't know Zen Cart so I'll leave that one alone. The admin side is so large, things get difficult - but specifics would be useful. And again, documentations and demos are coming.


Now, perhaps this would work better - can you tell me a specific problem you are having or action you are attempting to take that isn't working? Perhaps working through a few test cases would help. I find learning by doing to be very effective. i.e. are you trying to add a page? Are you having difficult realizing how to submit a ticket? What is it exactly that you are trying to do that becomes cumbersome, or what is your goal that you are trying to accomplish? I think if we can first identify that and work towards accomplishing that, along the way we can find what areas we can best focus on to improve the user/admin experience so that the goal becomes easier to accomplish.

Perhaps we haven't been clear enough so far about where Dynamic went, and how Nexus is our future strategy?

In the past, we had planned two products - Nexus, which was a billing/support application, and Dynamic, which was a CMS. Apart from sharing the ips_kernel, these were completely separate products. Some time ago, we took the decision to change our direction and create a business framework. This is what is now known as Nexus. Nexus is an application framework, and you add applications to it that suit your needs. Dynamic became one of those applications. It's just as featured as it was, and just as important to us as it always was, only now it integrates with our other products too.

The Nexus core contains some common code, the overall interface, and system management functions like templates and settings. You then add applications as necessary, be it hosting, support, CMS or any combination of the ones we'll offer. Additionally, if your business has a specific need, you can whip up your own application and it'll run right within Nexus. All of this runs in one unified interface, so everything you'd need is in one place and you can easily jump between them at will.

I hope that clears it up a bit. Hosting is just one of the modules available, and no module is dependent on another being present. You'll only have to buy exactly what you need

Brandon and Rikki, my apologies with the term I used 'Hosting' as a replacement for the 'Nexus Core', so every place I referred to 'hosting' I meant the Core Application of Nexus, since it 'hosts' the add in applications. So please re-read my post with that mistake cleared up.

But this is what I mean...its kind of a huge animal with no real laid out definitions, publically, that we can all fully understand (yes there are hints all over the place)...thats why I personally would like to see a build out list of each component and its intended functions as well as how each works in harmony with the next one. A nice image for some of us guys also who would like to see it visually would be beneficial. BTW here's a GREAT clue, if you look at the Resources site, you will see 0, zip, nada for Nexus articles, how about publishing some stuff there to help clear up what each module does and keep it updated every 30-45 days or so.

BTW Rikki did a nice job explaining the differences (Nexus and Dynamic) however both Rikki and Bradon, you refer to Dynamic and Nexus reusing large areas of code, this is the confusion with me and so many others that I was referencing. We heard rumors of this great CMS (IP.Dynamic) and this it got shelved, yet from it was re-born two distinct products (Nexus Core & CMS[dynamic]) both of which share a huge amount of code? What sense does this make? Why not include the CMS in the Nexus Core, seems to me it would almost be a requirement from what I read on many peoples responses. This is what many wanted, did you not listen as a company?

I will clean slate my test server and re install again and get back to you next week with some more reports, things that are specific. Please understand I am not offended and my intention is not to offend IPS, but to offer back some insight to the company who is building a product that I (and others) need to fully understand and offer up good feedback in a variety of ways to get our points across so that we can all be happy with a great product line from IPS.

EDIT, BTW I am sure I am not the only one that really wants to see the power of the Nexus framework in a good solid demo. Part of this demo would be the main site, resources and forums all being given a unified look and put together under Nexus. Personally I think this would be your greatest sales point.

• Yeah demo's would be nice (sample sites of different genres).
• Add ability to connect IP.Board. Yes Converge is available but if I'm just using the Nexus and IP.Board then the ability should be there without the extra steps of setting up & installing Converge.
• Add more built in features to CMS ie no brainer blocks such as: Latest Articles, latest posts, latest Downloads, Latest links, latest blogs, members online, latest member, top submitters, random gallery image, rss feeds block, social bookmarks, subscriptions, pay to access, statistics, built in menu block, layout change feature, Latest News, global announcements, banner rotation, video section, podcast/music upload section, Directory section, Link submission section, blog section, gallery section, Helpdesk and etc.
• Add profiles to Nexus or ability clicking members takes them to forum profile if applicable.

The reason I like to see the CMS greatly enhanced is I can't fathom dishing out a lot of money to invest more work and time into building pages inside of Nexus that could be easier accomplished using Frontpage, Dreamweaver or MS Impressions. My idea of using Nexus & CMS module is to avoid the hassle of burning up my brain to build custom pages and layouts. However I still love the fact that if my skills become better over time that the Nexus CMS will allow me to write custom stuff which Nexus currently has but a good percent of us are far from that level of expertise.

Admin navigation not user friendly:

• yes simply saying it's not friendly as many have said isn't enough to help the designers make it more friendly. So my suggestion is a dual menu system. The current as it is and then maybe 8 or so 80x80 icons layed out 2 rows in the center of panel to represent each group of main settings/tasks for us noobs or should I reference them as quick icons to easily get where you want to be without seeing any of the unecessary stuff that has nothing to do with the task you are seeking out? I just feel it's just way too much clicking in the back end to do or find simple things that should be easy. No one should need a book for things that should be obvious. So before someone wastes a lot of time writing up documentation for the backend settings, I think this suggestion should be taken into consideration since so many have mentioned the offness of the settings but none have really not offered up any suggestions of improvements.

You might be interested to know that our entire billing system, main website, resource website and client area run in Nexus, and this board is also hooked up to it via Converge As a company we already very heavily use it

Yeah we already knew that for over a year plus now I believe including myself what everyone is looking for when they say live demos is "Alternate" scenarios of the various uses for Nexus and it's capabilities previewed in an extreme enviroment case. IPS Client center is only one view with the second being the resources home page which pretty much blows(bfarbers portal is more functional than what's there currently considering his portal is not even a CMS). Other than that I have only seen one live sample and that is FNN's site which pretty much everything he has done can be done with the simple cms included with Nexus(everyday basic html). I like to see some real power demos that justify purchasing the Nexus, CMS modules or other addons.

Seriously, we haven't a clue about the pricing and with that said, if I were a "Business" and interested in Nexus for its core and CMS module would it be to my advantage to purchase the two items and if so please elaborate why? What advantage would the CMS module have over the simple CMS included with Nexus? What are the exact feature differences between the simple cms and addon version cms?

NeverLand:
Right now all we have is a Nexus feedback forum and there is no subforums for addons which I think would better employ feedback of individual modules especially for those that are utilizing one more than the other and can give the best feeback without it being lost in the weeds in "one solo forum". As you can see in this topic we are going back and forth on various subjects which is very distracting for me so I can only wonder how you guys keep up? The integration of both forums have been compacted so much that there is hardly room to exhale or breathe. It was so much fun at IPSBeyond and now it's like a mini battle here. Don't ask me why, maybe it's because this site is limited in forums that voiced out opinions stand out a bit more? The upside is that we no longer have to be annoyed by over zealous moderators closing our topics prematurely or moving them (ITO) to Neverland because there isn't really anywhere here to move things now lol . IPSBeyond was compacted down to six main forums on this site It's way too much activity to be trying to look at anything older than last recent posts at this site or to reflect on a topic thats lost in weeds because of the integration and compact size of forums here.

Before you guys even start writing a book, I like to see specifically the features of each product first. We atleast deserve to know that even if the price is not yet determined. Every release so far we are flying blind to features.

IP.Nexus 1.0.0 Beta 1 Now Available
http://forums.invisionpower.com/index.php?...t&p=1508548
IP.Nexus.Core 1.0.0 Beta 2 Now Available
IP.Nexus.Billing 1.0.0 Beta 1 Now Available
http://forums.invisionpower.com/index.php?...t&p=1511235

IP.Nexus.Core 1.0.0 Beta 3 Now Available
IP.Nexus.Billing 1.0.0 Beta 2 Now Available
IP.Nexus.CMS 1.0.0 Beta 1 Now Available
http://forums.invisionpower.com/index.php?...t&p=1515506
IP.Nexus.Core 1.0.0 Beta 4 Now Available
IP.Nexus.Billing 1.0.0 Beta 3 Now Available
IP.Nexus.CMS 1.0.0 Beta 2 Now Available
IP.Nexus.Hosting 1.0.0 Beta 1 Now Available
http://forums.invisionpower.com/index.php?...t&p=1689483
IP.Nexus.Core 1.0.0 Beta 5 Now Available
IP.Nexus.Billing 1.0.0 Beta 4 Now Available
IP.Nexus.CMS 1.0.0 Beta 3 Now Available
IP.Nexus.Hosting 1.0.0 Beta 2 Now Available
IP.Nexus.Downloads 1.0.0 Beta 1 Now Available
http://forums.invisionpower.com/index.php?...t&p=1699062

Lastly again, I think Nexus should be self capable (enable/disable settings) of integrating with other IPS products without the need for Converge. If someone wanted to use Nexus with VB, PHPbb, WordPress, SMF or some other non-IPS product then I can see the use of Converge and its true potential. However, as I mentioned and I never get feedback from IPS view on this subject... Why on earth would you require converge with your own products? It just doesn't make sense to me.

Well Converge is 'built in'. Either way you'd need some API between the board/Nexus, and that's all Converge is. Converge is the API between the products so they talk to each other. I'm not sure how else you could make them integrated other than having the board code in the Nexus code and vice-versa. Converge is just a middle-man between the products.

I guess I'm wondering the need for Converge when it comes to IPS products? I can see it's use for integrating things outside the realm of IPS products, but I just don't understand why IPS only clients need Converge to combine IPS products or subjected to the extra steps to combine them? Like I said, it's a cool idea especially if I want to connect a non-IPS product. However, if I'm using only IPS products ranging from IP.Nexus to IP.Board (the only two available right now) currently why the need for the middle man? In any case wouldn't it just be simpler to provide Nexus with Converge built in and still offer the solo version of Converge for those who don't purchase Nexus? I think it would make the Nexus setup with IP.Board or any other product a heck of lot easier and streamlined. The advantages to this is already self apparent. Just a nice suggestion to make life easier

Also, don't forget to include/create a tools/modules for better integration with IP.Board, IP.Blog, IP.Gallery with IP.Nexus.

Ideally, would be to have a product (IP.Nexus) dedicated for both business and for customers who want a CMS that will be able to offer optimal integration with current product already buyed at IPS.

Here's hoping I don't go over the quote limit on the board



I will concede this is true, but it is becuase of the fact that the product is very much in BETA stages right now. You need to keep that in mind. It is very time consuming to write documentation, and take pictures or make video demos. When we've changed the interface 6 times in the last 6 betas, it doesn't make sense to spend the enormous amout of time on this sort of thing when we'll just have to redo the work.

Documentation WILL be available and we WILL have articles on the resources site. I assure you. Documentation has already been started, in fact, and is not being done by a developer. I personally intend to add a few articles to the resources site - specifically about how we pass permissions from our client area to these forums via Converge (since I'm sure that information, generally, will be useful to others looking to do similar things), as well as how we've setup the resource site with the portal and the links system, and so on. It's just a matter of focusing our priorities. It makes more sense to get Nexus completed first and then finalize documentation and demos.

In other words, we fully agree this is important, and we will be delivering this aspect of the final product. We just can't do so yet.



No, no. Nexus Core + CMS does not reuse any real sections of code. The old Nexus (the billing and hosting application) and the CMS (Dynamic) reused large sections of code. User management, templating, session authentication, core files (such as XML processing and database drivers) and so on. All were very much the same (or similar) between applications, but had to be maintained and installed separately. In theory, this could have taken up an extra 20MB or more of webspace on your server if you were to install both applications (that is, 20MB of the same code but from different installations). Instead, we developed the core which has the shared functionality between the systems, and then ported the code for the CMS to run through this core.

At the end of the day, Nexus + CMS is effectively what Dynamic used to be. And, I'd venture to say, is going to be priced at the same level that "Dynamic" would have been priced at. I really don't see the problem with this.

If you wanted a store and a site, you'd have needed to have Nexus and Dynamic both (previously). This means managing members in two different places. Managing system settings in two different places. Managing templates in two different places through two slightly different systems. That would have been a nightmare! Now, you can do it all from one interface. And if you DON'T want the store, you don't need to buy it - so at the end of the day we didn't force anything, in fact we provided more options.

Again - Dynamic did not get "shelved". All it did was get abstracted so that it could run side-by-side with the store much easier. The Core is not exactly a "distinct" product. It's like a host, as you clarified in your first response above. It just hosts the actual applications you wish to run through your site. A lot of people may not have a need for the CMS - that is why it's not included with the core. If we were to do that, we'd have to charge people that only want the store for a CMS, when they don't want to use it. Why is it a problem if YOU want the CMS to get the core and the CMS? And if someone doesn't want the CMS they aren't forced into getting it. Basically your suggestion is to remove a key option that is presently available with no benefit coming out of it. You wouldn't GAIN any functionality that isn't there now! That is the important point to remember.



Demos won't be possible until people actually start using it. Our site is a good solid demo of course. As is the resource site. But we have better things to spend our time on (such as developing the product) than setting up and configuring bogus demo sites at this point in time (all of which we would then need to try and maintain too).

The problem is, Nexus is a separate application. Period. Anytime there is a separate application you need a layer to sit between the two you are trying to have talk to each other. That's all Converge is. You don't even need to know it's there. This is hard subject to handle differently...though I will be fair and say that with some small tweaking, instead of using Converge you could use the "external" login handler in either IP.Board or IP.Nexus (depending on which one you wanted to be the master) to connect to the other database for authentication purposes.



Hmm, you mean like a shortcut system of sorts? That could be a good idea. Something akin to what is on the Overview page of IPB 2.3 (but with more of the quick jumps)? Trickiest thing I could see is dealing with how to dynamically add and remove the options depending on the apps installed combined with what the viewing user has permission to access, but there are ways to do that already in Nexus.




You are wayyyyy off base here. My free portal system doesn't come close to Nexus - and I can promise you that from an insider (in both cases) perspective. My portal system can enable and disable some fundamental blocks in IPB. There are no fundamental blocks in Nexus. Your site is what you make it! How can we have basic turn on and off blocks? What would those be? Someone may want a weather feed - someone else a news ticker - someone else an RSS export from some other page on their site. All of this functionality is entirely possible with Nexus, however there is no cookie cutter way of turning it on and off. It sounds to me like what YOU really need is a portal and the ability to make custom pages. You don't fully comprehend what a CMS is and how it is used.

FNN's site is a lot more than just some basic HTML pages too. I'll let him explain that to you.



The entire Articles System, which is probably about the most powerful feature of the CMS, is part of the CMS and not the core. That is, making dynamic news entries, and well, just about any section of the site. On the resources site, for example, News, Wiki and Links are all run through separate instances of the articles system. RSS importing is done through the CMS. IP.Board content sharing (and likely other IP.Board integration options as we implement them). There is a file management module and there are content-blocks (which I've explained in this forum what they can be used for, though you admittedly can get away without them if you like to duplicate your work). There is a dynamic poll module (allowing you to create an unlimited number of polls dynamically to be included anywhere on your site) and a dynamic forms module (allowing you to create an unlimited number of forms and have the application manage those forms and responses). There's a revision manager, which works for templates, articles and so on - allowing you to revert to a previous revision of something (a very very powerful feature...). There are other miscellaneous features too (error page control, domain entry point mappings to allow you to point domain name requests to different pages of the site, and so on), but the above are the meat and potatoes I'd say.

Trust me, comparing Nexus CMS to my portal is like comparing Windows to Notepad. They're two different things on two different scales.




I can agree about the Nexus forums - it's not a bad idea. Though it would probably wait until we went final. The IPS Beyond forums, however have many subforums. There are 6 categories, but there are a lot of subforums in those categories.



This will be done at some point I'm sure. Documentation has already begun, however, so it won't be before docs are started.




Converge is simply a layer between the applications (Nexus and IPB) which are two entirely separate installations. There is no way to make them "merged" into one. You would need a layer, regardless of what you call it. Converge just adds more flexibility by allowing it to be hosted elsewhere and allowing multiple applications to all feed off of one central database. This should be it's own separate discussion however.




This will be an ongoing effort, for sure.

I'm gonna be more than happy to share my demo of nexus for my site. Not ready yet .

Rikki, you missed the point again. The point is if they are all using the core product (the sites being the main site, resources and the forums) why do they all look and function very differently? Shouldn't they all at at least have a similar header (menu system to move around) and footer? Really, same company, different products? Okay, but if they are all on one site showing integration (background that we all don't see) they should share a similar foreground in look and feel? Granted you can't make every thing "fit" in to a template, but you can template the headers and footers and give it a similar theme, which would support the unified point. Not to mention, don't you think that this will be the goal of those potential customers for their sites? Is there a goal for a unified skinning system?
----
China thanks for your POST, good ideas and points! It was a nice follow up to support what I too have been saying. http://forums.invisionpower.com/index.php?...t&p=1709218
----
bfarber I am going to nominate you for a political seat...nice double talk :lol, but it seems like you cleared this up a bit, however this little tid bit of info contradicts the more prominant diseminate infor that they do share the code. Here is a perfect case for release notes, more on that in a sec.

Thanks for FINALLY clearing that up for all to fully understand!
----

This is WHY WE keep wondering why not just release "Nexux Core" + "CMS" as a single unit. Seems to many that this is what was introduced in Dynamic and what everyone wanted in the first place. To separate them, just because of a huge download is just silly. I get most of your downloads on my cable modem in less than 3 minutes, even the hefty core which is back up to 13.74mb.
----

Not to be too rude, but very to the point, HORSECRAP!
I did beta testing for Microsoft for many years as well as many other companies, the major difference is, other companies betas where a sign up basis and we got the software for free or at a MAJOR discount. But the point of this is to state that they sent out a "release for betas only newsletter" which pointed out the differences between builds/enhancements and supporting screen shot and/or bugs. They also included new links to each new release section to separate previous versions from latest versions to keep everyone on the same page.

If Invision is looking to sell their products then you should probably structure your feedback better so we can give you better feed back. And for the record I am no longer the only voice now 'Barneys Girlfriend'ing about this, I certainly hope others join in and demand better documentation on beta releases. Is this a pain in the ass, YES, but it is also a precursor to quality control and user functionality.

I brought this point up in the hopes that you would STOP using the forums to post "IP.Nexus.product vX.X.X Beta X Now Available" with minimal info and start using the Resources site to post details about each release. This way people can see the changes. I would also expect that there would be links back to the forum topic areas for EACH product and its version that are pinned. With the release of each new version the old gets unpinned and closed so we all stay on the same page. Sure thats a bit more set up work, but hell I would do that much work for you just for the benefit of the community...sign me up!
----

While I understand your clarification as well as your argument, I still don't see anywhere, where anyone has stated that they would see the CMS as NOT beneficial and are glad you separated it. IPS touted Dynamic as the CMS product by IPS, which is what many of us wanted for 2 years and now you separate it? Not Smart, especially since the Nexus Core has a simple CMS in it, huh? Don't you see the consumer confusion? It just looks bad, kind of like IPS wants more money after the fact, because in simple terms, the intelligent observer would be asking at this point "Why not add user database control to Dynamic and call it a day?". Fantastic that you created a single place to control users in the Core for all IPS products, that TOO is what we wanted. Great, opens up the door for the future, we get it. To split them...wow this still creates quite a bit of head turning.

Before you slap your hand on your forehead, I know, the Core is like a hosting/docking system for other IPS components and it does more. All I am saying is, what is IPS's point to run PR off for 2 years on a CMS product then change it's product so radically that it now requires a 'hosting/docking' component called Nexus Core? Just include the CMS with it and many will be happier. Once again who doesn't want or need a CMS? I would love to hear from those who were dying for Dynamic and now agree that this split is good....I'll look up your posts too.
----

This is just fair season on not thinking before responding...but I'll go easy. Demo's are REQUIRED to Beta testers to see the desired implementation by the developer for comments and comparisons by the Beta testers. It's kind of like the reference boards products by hardware manufactures so that other developers and testers can see the desired goal and make suggestions and improvements on the reference model. Again if you are in need of a new staff position, I am your huckleberry, set me up I'll turn the thing on and work with your team to make it a running reference model.
----

This brings up an interesting point akin to documentation, but the entire work flow of each module. How do you get certain things accomplished in one and what functionality is built up with another. But more to the point how do you go about publishing parts of the componets to the site. Again the documentation should cover this type of work flow. Specifically the bold point in your quote...things like this should be in the Resources side of the IPS site in the articles section for Nexus.
----
Once again I stress that my responses are to encourage thinking about documentation, user interaction and the development process to better the product. Thanks very much bfarber for sticking your neck out on the perverbal chopping block in the interest of making a difference.
----

Well, actually I believe you're missing the point. The board is the board. We always intend to keep this board as default as possible, so people can see this is what they get when they have their own board. Our website is our website, naturally we need it to be unique. And we prefer our resource site to be differentiated from our other areas (although the header of that site borrows from our main website to keep some branding).

The skinning system is 'unified'. If you want all your different areas to be the same, that's what it can do. We have different needs for each thing we do though. We aren't going to force everything into one header/footer because there's no real reason to. Yes, our website and resource site are also a demo of Nexus, but we can't just abandon their individual purposes to support that

In time we'll have 'true' demos of Nexus.

Because why should you pay for a CMS if you don't need a CMS? They aren't separated because of a big download, they're separated because not everyone will want to buy the CMS module. Plenty of people don't want a CMS. Plenty of people are just interested in having the billing system.

I do agree that a changelog between beta versions would be beneficial... I'll try and work on that for the next release.

So we can buy the CMS and get Nexus Free?

wburdine, let's go back to the CMS portion real quick.

Let's say the old Nexus (billing/hosting/support) application was going to be $15 (this is not the price, this is an example, $15 is $5 x 3 different products in this example).
Let's say Dynamic was going to be $5 (this is not the price, this is an example).

Now, let's say with the new Nexus setup, you get Nexus core + CMS for $5. And you can add on the Billing application for $5.

Now, instead of paying $20 for both applications that we had, you pay $10 and get what you really need (say you don't need hosting support). Or let's say you do need all of the prior applications as they were - you still pay $20.

What is the issue? CMS + Core is "unified" as you put it - it all runs under one interface. Just because CMS is a separate tab in that interface doesn't really mean much in the long run. It's still the same thing. I really don't understand your argument regarding putting it together and sell it like that. If we did so, someone who only needed a store would now be FORCED to pay $10 instead of $5, because they would be forced into buying the CMS. Just because YOU want the CMS does not mean everyone will.

wow the application is only $20 thats great, i'll send some money in now of course this post is legally binding...

I think that Nexus will be around the same price as IPB for the core. The extra stuff like cms, hosting, billing and downloads will be around the $50 mark.

OKAY I GIVE UP...unless some one can understand English and rephrase so that these guys will understand what a dangling carrot once was and now is an apple AND Just WHO (customers) on this site got excited about Dynamic and now is GLAD that the CMS module (formerly Dynamic) is NOW and EXTRA expense because it won't run without the Core? Can you say bait and switch?

I would be HAPPY to discuss it with you if you want to call me IPS, because it seems like I am not writing in the same language you guys are reading.

Sorry, my apologies that this topic got off the purpose for which it was intended...

Yeah I hate visiting car dealers that don't post the price of the vehicle (they will never get my business if they can't be upfront and need to play games) , but instead want to suck you in to call them, return visit or whatever. This hidden pricing on Nexus has went way over the top. The number one complaint is people want to know if they can afford it or not, maybe have an idea of what kind of money to set aside or something. The last thing I want to be is sticker shocked. So this torture of "we haven't decided a price yet" has gone on way too long... Please throw us a bone and spit it out for Pete's Sake.

Most of my complaints I truly believe is the beta testing blindly as to whether I can afford it or not as well what will I get for the money I spend if I can afford it... So lets push for more features just incase it is outrageous to justify the pricing amps my attitude I think.

I'm just really sad as I have so much going on in my life that I know in some way or another from my posts IPS is getting the short end of the stick and I apologize for that. There may be people with greater or lesser issues than mine that are participants in this topic, but I think that IPS needs to throw us a bone or something so that the percentage of us in the end who really may not be able to afford this product including needed add-ons can find other alternate solutions to meet our needs. IPS famous Quote "Nexus is a business solution and not for everyone".

I'm sorry, with respect, you seem to be the one misunderstanding, not us. We've said in this topic and elsewhere that the Core + CMS will for all intents and purposes be what Dynamic was, both in functionality and price. How is that bait and switch? It's what it was, only now it has the added benefit of being able to work seamlessly with billing, hosting or whatever else you want (or don't want, if that's the case). There's no additional cost if you just want CMS. You buy the Core + CMS, and that works out at roughly what "Dynamic" would have been.

From the Dynamic perspective, all we've done is take out the 'grunt' code (member handling, basic programming functions, etc.) and put them in a core that other business products can share. The rest of Dynamic is largely as it was, although for branding purposes it will be an application of Nexus.

I've tried to explain this as best I can, and other people seem to have grasped the idea. The core plus CMS application is almost exactly equivalent to what we previously called Dynamic.

And I'm afraid there's no 'hidden pricing'. We simply haven't announced the price yet. That's not uncommon at this stage - we aren't even in RC yet. We truly haven't decided the price yet, because we haven't finalised the licensing scheme we're going to use. We certainly have ideas internally, but what's the point in announcing unfinalised licensing plans? When we're closer to release, then of course we'll be announcing how much it will sell for. We aren't at that point yet.

Sorry to infer hidden pricing. What was the price for Dynamic? I mean I'm just trying to gauge a rough idea for example would the price (Nexus & CMS) be somewhat close to the Community Suite pricing (IP.Board, Gallery & Blog) or is it mostly likely double that amount? I'm asking this without specifics but just a general idea. You mentioned the Dynamic price above in your reply as a certain for what it was going to go for in comparision but I don't ever recall any Dynamic pricing announced or maybe I missed it?

No pricing scheme for IP.Dynamic was announced, I'd imagine that again there were internal ideas around licensing/pricing, but never anything solid enough to release, as IP.D never made it to even