Hmmm
Trying to install this on a local Wamp dev box and can't get past the error message,
"Facebook needs the CURL PHP extension"

I have the curl extension installed (php_curl) and configured in my php.ini file (extension=php_curl.dll)

Any thoughts?

Incidentally I also had to enable "short open tag" in my php settings to get the install to run but that was expected at this stage of development.

Liking it so far, already have some sketching done for some themes based around "Gathering", probably, along with Redactor, my fave new feature.

Only thing that kind of stands out to me is the absence of any kind of highlighting of editable areas, until they are rolled over, you start out on a pretty blank page, you hit edit, you're still looking at a pretty blank page, I would question the newb friendliness of it.

Js and css get bigger and bigger close to 400 mo for both ccm.app.js and ccm.app.css

Yeah, the ccm.app.js definitly needs a work through.
Screenshots look nice :)

Just two quick remarks or Newer is not always better

1) Adding a new block:

I was looking forward to improvements, but at the current state, i can see no advantage over the old method. In order to add content, i have to click the + button, wait 3 seconds until the block icons window gets loaded, which is then overlaying the page, while i have to drag the block icon out of that window in order to place the icon behind it (!) onto the page. Ok, the window disappears as soon as the icon is grabbed, but that's a strange procedure anyway. In my opinion it's simply not logically consistent to drag elements out of a pane in order to place them behind that pane, even when that pane immediately disappears.

Why didn't you take the approach with the block icon bar on top, as you showed in an earlier Totally Random Show (similar to the way how ImpressPages handles that)? That icon bar could also have an autohide functionality to save space...

2) Block markers

Now we see the borders that mark existing blocks and available areas only by mouseover, which means one has to painfully poke around with the mouse, just to recognize the structure of the page and where to put the content. The old style was way better! Please, don't kill well-proven features that make sense, just to be stylish. While i like the editor bar to edit blocks, i find the constantly popping up of panes and icons on mouseover rather annoying.

To be honest, personally i cannot see that recent changes as a big step forward. What i would have liked to see much more than javascript play and eyecandy, are enhancements to the stacks stystem and the filemanager.

Overall looks nice. I like the direction it's going with gatherings and conversations.

Couple of things I noted.

Sitemap is dead for me - shows home node only and will not expand.

Installed a couple of our marketplace themes I get this on the two I tested (Heart concrete5 and Venture)
Fatal error: Call to a member function getTotalBlocksInArea() on a non-object in /Users/ol......./concrete571wip/web/concrete/core/models/area/global.php on line 26. Everything broken as a result.

Added some of our marketplace blocks - Many are broken in the add/edit screens, no bootstrap tab and not picking up their Bootstrap UI styles. One in particular - Formigo Slider will not load at all.

I'm relatively relaxed at this point, as I know this is a very early release and you didn't have to let us have a preview this soon, but hopefully we won't have a ton of work to do to make all our stuff 5.7 compatible.

Best

Ollie

A few comments

Likes
1) minimalist ui. like it.
2) cleaner menus. like it.
3) social features. like it
4) conversations and discussions. like it.

I like these things and a few more...but honestly, I'm mortified at some of the losses. Not much needs to be said about the plusses. You're doing great and they are coming along nicely.

Dislikes (qualifier - I'm on 11. you know this. not a surprise. But despite you not liking how I'm saying things - there are some very legitimate points here.)

1) forcing composer use. I don't like it. But I do get it. Or at least try to.

2) no immediate feedback on where block areas are - I don't like it and is a very serious & detrimental design flaw. The overwhelming majority of response on this one for anyone that has used C5 prior to 5.7 will be very negative. When I am training a client that is not very web savy, I have literally sat and watched without instructing them log in and play and immediately identify what to do. Not having area highlights is going to hurt that learning process. "so easy your grandma could use it" is all but gone with this move.

3) I view the block icons with big squares largely as wasted space, and most definitely not mobile friendly.

4) icons larger than the name of a block is really lacking in user interface design. You have to squint to read what it is. Pictures are nice....but not intuitive. You can have only words with no icons in an app, and people can stil use it. But if you have only icons and no words, usability goes way down. (exempt a few obvious gimme's) this fact should speak to the ratio of icon to word design. It's obvious this has not been considered.

5) You should really consider the idea of people working with their sites with a tablet. Because people are. And if C5 is totally neglecting that use case - they will drop your platform. At this point in time - this is something you should largely be aware of, and in my mind should be a given expectation provided todays fastest growing web medium - the tablet. I just don't see 5.7 as usable in a tablet context whatsoever. the design flaw you are missing here is this - "there is no 'hover' or 'click and drag' on a tablet." I can only surmise that your intent is to develop a mobile app for this use. But even at that, it wouldn't' be "in context" at all which is what draws people to C5 to begin with. Perhaps you see revenu opportunity there? not sure. My point is this though - it was so close to being usable in a tablet context as it was! Now you're just steering clear away from it all together instead of stepping up your game. That's a shame.

5) suddenly, marketplace integration and addon extension is immensely difficult to find. Just to install an addon now you have to do a live search. Not sure why you are so convinced that live search is the answer to everything. It's not. Some people want a link. They just do. And yeah, someone could favorite it....but again, because of how you present things (or don't) - hardly anyone even knows you can do that! lol So....no, they won't. they don't even know you can do that. So that leads me to believe addon sales will be very negatively impacted by this lack of addon/marketplace presence. That's a real shame.

some finer points I'm taking away from this preview:

- we want to shove composer down peoples throats. "people aren't using it...so let's MAKE them use it!!!" lol Buawahahahahaaaaaa (evil laugh)

- we're more focused on being pretty than usable. Screw the fastest growing web use trend in the world! tablet users - who needs'm!!! Besides, we're pretty, and we'll suck them in with a pretty mobile app anyway!!!

- remove as many links and menus as possible because we think live-search is "neat-o". (hence the overly ominous search input) In fact....I think you should have NO icons, no words, no links, no help text anywhere. Only live search. Lets's go that rout. sigh....

- continue to diminish marketplace integration as a selling point. It's a thorn in our side that we regret ever making that has not turned out the way we envisioned. aka - we don't like it, it's not profiting us enough for as much PRB costs us in time and resource, lets all but scrap it.

Just being honest. I'm sure you expected nothing less.

Sure...much of my input is filtered through marketplace sales. I'll be open and honest about that.

Selfishly, I want to drive more sales. Not less.

Because without them, I'm relegated to just another webshop instead of being able to really manage and buff these products and their feature sets. More sales = more time to make them better. Less sales = me taking on more jobs that have nothing to do with those products.

From my perspective, I wish you'd push the marketplace half as much as you're shoving composer and live search in our face.

What I see instead is it getting more and more diminished.

It's all but removed from this iteration of 5.7. I'm HOPING that's simply an oversite.

ChadStrat

A few thoughts to share in general to emerging questions/thoughts here and on twitter...


1) short tags/table count/JS & CSS size - yeah its a developer snapshot. This stuff will get more efficient as we get closer to a release. Tangentally I've never understood people who consider a high table count a flaw. It's not like MySQL charges you per table, and its not like dumping all data into one flat data store table is a great architecture solution. This always has struck me as judging a car's value on how many wires are under the hood.... but i digress...

2) Composer. I'll be the first to admit there's some polish to add here, but I firmly believe we're on the right track. Creating something new is fundamentally different than editing something that exists, and every time I explain "to add a sub page you have to goto where you want it first..." eyes start to fog over. I recognize that there are times where an author will want to quickly get past the form and start editing in page - I think there's stuff we can do to the composer experience to make that feasible. That doesn't change the fact that managing un-published pages in a centralized drafts area makes way more sense than reminding yourself that the press release you can see on your site isn't live yet because you're 100% you always hit preview instead of publish.

Some of you may have add-ons that lose sales because we're building more flexible ways for data entry to be designed on the fly. Frankly this is the one compelling feature to expression engine, its something people are constantly doing with single pages for clients (sure let me build you a boat entry form for these pages) and if we can make tools everyone can share for that to be easier for clients and developers - that's our job. I believe new opportunities will always emerge in the marketplace. We didn't build a marketplace of stuff and then a CMS to shill it. We've always been willing to change things in the core that we believed were just a better idea, at the jeapordy of our own sales as well. We're clearly giving up any sales on Discussions and likely Calendar as we move forward with 5.7, so we're all paying a price for moving forward.

3) Tablet UI. We agree with the consensus that this is important. We simply haven't worried about it yet. There's no plans to sell any mobile apps, just to make em eventually.

4) Adding blocks changed. - nope. The plus is simply a new additional way to add a block. You can still click a block area and add a block by clicking it from the list.

5) highlights and area borders. This one's pretty tricky because its super subjective and I believe it takes a little time to get used to something different - so its difficult for me to accept absolutist feedback less than 24 hours after the first release. I agree its a significant change. I also think that putting a page in edit mode before added too much cruft. Things moved around because of the dotted lines, and the whole thing felt clunkier than I'd like. Looking at just about /everyone/ else that's succeeding with in-context editing shows this approach can work just fine. While I love the vacuum cleaner/dog analogy on our home page, I have a hard time believing your clients are any less comfortable with technology than wix/weebly/squarespace customers. Each of them is much closer to the minimalist 5.7 approach than our dotted line 5.6 approach. I guess to respond to a point made here, our goal is actually that yes - the editor wouldn't /have/ to worry about the page's structure (which all the dotted lines help with) as much as just what they wanted to put on the page..

Look at it this way. 10 years ago CMS's were like letter presses. You had a completely different experience creating content than viewing it. Then back in 2003 we started doing in-context editing well. Now it's 2013 and every decent SaaS cms takes the in-context approach and many of the leading open source ones are trying to dance with it using modules and extensions. It's clearly the way forward. Much like the 80's and software like Quark or Wordperfect - the read & edit in the same place thing starts as a big mental leap with lots of UI to make you feel comfortable. Those apps in the early days had lots of strokes around text areas, Print View vs. Draft Mode -etc. As time goes on and people become more comfortable with how that works, and application designers become more comfortable with what they can pull off, that chrome slowly fades away. Now google docs lets you just write on a empty page. Click the Untitled label and you're editing the document name. That's a huge evolution, but it's how these things go.

That being said, I'd be the first to admit that we're still experimenting with what should highlight, how that should look, etc.. I also have concerns that we may have let the pendulum swing a little far in this developer candidate, so worry not. This stuff is still being dialed in, but yeah this is the tune we're playing. The future is fun.

6) Marketplace integration, sitemap not working - anything else like that.
Nope, not a decision just a lack of attention at this point. We like the marketplace and its an important part of what concrete5 does. No that doesn't mean we're going to shoot the core product in the foot to make sure nothing changes in terms of the add-on sales ecosystem, but yes we like selling things.

Franz,

I'm with ya. It's early. There's some really great ideas in this song. I like the rhythm. The concept is good. The melody is being really hurt though by the lead up /pre-chorus to the real point of the song - the chorus. which in my mind is intuitiveness. :-) Feels a bit like when your guitar player first discovers a ring modulator. It's neat....but to much is to much. That's how I feel about icons. lol Mankind developed from pictures to words for a good reason. picture + words = win in my mind.

@mainio - I have the exact same take on live search. I, and others I work with rarely use it. It's almost seems like a bandaid to a bigger problem - the lacking overall intuitiveness of where things are. To me, it seems like it could be a tool for finding things once or twice, so you can then organize and prioritize the applications and functionality you USE. The favorites is kind of in this veine ....but it should go farther. Application Single Page icons, positioning these links more prominently...ect, to make your favorites feel more like the application as a whole.

I also agree with your take on page publishing as it has been as an alternative for people that like that. It would also make people feel less "constricted" to composer publishing. I have yet to work with anyone that really likes composer. just being honest.

ChadStrat

1. No. MySQL doesn't charge by the table. And I'm a fan of normalization.

But MySQL does charge by the join. And more tables typically means more joins.

It's kinda like judging a car's potential for having difficult and/or expensive maintenance by how many wires are under the hood. Thousands of wires doesn't /necessarily/ mean it's going to be more difficult to maintain, but it often ends up that way.

2. Hmm.. I see the argument for Composer, and I thought it was a great idea to add it as an option; I've used it as THE way to create some page types.

But I think "goto where you want it first..." is pretty damned intuitive and I find most clients get it quickly. People are pretty good at mentally picturing trees and "parents" and "children". If I'm working on a word doc, and I want to add a new paragraph, I go to where it belongs, not to a "add paragraph dialog box".

On the other hand, I've also had an occasional brain fart when adding a new page and I put it under the wrong parent. (And I find it annoying when adding lots of child page "placeholders" (go to parent, add page, publish, remember to go one level up, repeat).

I think the easy (and pretty useful) solution is to have the standard "add page" button and popup, but make it really clear where the page is going, and offer an opportunity to change it. So if you hit "Add Page" from the Home, you get the current popup, with something like a breadcrumb "Adding to /". And you can use some sort of tree or live search to change it to wherever you want.

5. I think the weebly analogy only half works. I think that it's more intuitive on those sites what is editable and what isn't. By their very nature, c5 areas are much more "random". Some page types might pull everything from attributes so while the data shown might imply it's editable (it's data you've entered at some point), it's not. And this depends on the theme and/or page type.So it really helps to have something point that out to you. 3px wide red dashed lines might be overkill, yes....

Highlights and Area borders: What about adding a button that toggles a border/highlight on and off? This way the user can decide what works best for them.

I'm looking forward to this release, it's looking great!

Just a suggestion. You could use box-shadow around the areas so people know its a block that can be added to.
Box shadow doesn't push the layout out by 1px. Even better you could use an animated box shadow to give a fading in and out effect that would keep it looking cool! :D

If this feature is not in the core i bet you could just add it in yourself by targeting what ever class is wrapped around the block area with your CSS.

An "Undo" action would be better than hitting "Cancel" and throwing a second prompt.

Citation:http://goodui.org rule #8.

That'd be great but then you'd have no way of "undoing" your action of setting the block in edit mode in the first place. Your only way out would be the "Save" button which is not very tempting to press if you accidentally opened the edit mode. Or at least I don't want to "Save" anything I did by an accident.

Other way would be to change the "Save" button to "Close" but then the possibility to "Undo" the action would be limited to discarding all changes you've done to the page which I don't believe is a good solution since you might've made other changes as well.

I'm not also saying the confirmation is the right way to solve it, my initial wording was "the button is too close", so it would be just enough if it wasn't next to the "Save" button. I just said the "confirmation" because that's what I'd expect when it's few pixels away from the "Save" button.

By the way, I'm sure the core team has been checking out the competition but just for the record, I think the image positioning inside the content here is very attractive and easy:
http://www.squarespace.com/

Might not be that easy to pull off but that would be a very easy way of positioning images in the content. I don't think the auto-column feature is that appealing, since you can already make columns in c5 and sometimes I prefer floating images, but if I could just drag an image to where it belongs, it would be great and very easy for the user.

Does Redactor even have it's own 'Undo/Redo' button? Isn't that a basic requirement of any editor these days? Clients rarely know about CTRL-Z & CTRL-Y.

Thanks for the feedback so far. Franz has addressed many of the items posted here but I wanted to add a couple things to his list.

- The increased file size in CSS and JavaScript is due to new bootstrap, and almost entirely otherwise related to the inclusion of Dynatree, which is a JavaScript library that builds tree-style menus, like the one in our sitemap. We wanted to use these type of tree-style menus in a couple other spots in the 5.7 dashboard (which aren't done yet, so don't go looking for them ;-) ) but our sitemap.js was very much geared toward one purpose. So we removed it, and have rewritten it as a jQuery plugin that uses dynatree, and it's going to be much nicer to use as a result.

- As Franz said, we have put zero effort in on mobile at this point, but going forward our mobile strategy with the core is going to be less concerned with "mobile themes" and user agent detection and more concerned which just building a responsive menu bar, a fully responsive dashboard and core theme (core being the white theme that you get on login, register pages). Obviously our new design relies on hover for a lot of feedback so we will have to tweak this behavior on mobile, which we fully intend to do.

- Good thought on cancel in the inline edit bar. We probably ought to include an "Are you Sure" at the very least.

- You CAN add files and links to pages in redactor by clicking on the concrete5 icon at the very start of the bar. I imagine you probably thought this was just a branding logo or something like that (which totally makes sense and it occurs to me that I wouldn't know it was anything special either.) But within there you can access the old concrete5 functionality as well. We also might ditch this icon and just integrate our sitemap and file manager stuff right into the redactor modals, which we never did in TinyMCE because it was just too difficult to do. Redactor is much easier to customize.

- An earlier build of 5.7 showed all areas when dragging blocks. At some point I lost this but I don't think it was by design. I agree that we ought to show the area borders at the very least when dragging block types from the plus icon or around in the page.

- We are going to be fixing intelligent search in multilingual sites. We've been talking with Remo, bmatzner and mlocati about finally getting those pull requests into the core.

I personally would also like to see some love around cross-linking and intra-dashboard navigation. I agree that it's hard to get around in there, even though it's awesome that it's easy to jump to any page quickly.

Thanks for pointing out the logo! Yes, I certainly didn't notice it at first. I didn't think the logo had any functionality as you guessed.

I remembered you demonstrated those features with the first demo video but just didn't remember it happened through the logo and I thought this is just something that's not fully ready yet at this point.

The integrating opportunity would definitely get my vote, to make it easier for the functionality to be discovered. It would also make more sense if adding an image always happens through a single button, not two separate buttons.

Now after testing the image adding feature, one more point:
I didn't find anywhere where I could control the position of the image (float left / right, margings). This wasn't very intuitive in TinyMCE either but at least it was possible there without modifying the source.

Or alternatively, defining a class / predefined style could also do the job as you could add ready styles for floating images in the theme.

Thanks Andrew and Franz and the rest of your crew for letting us all in at such an early stage.

I had many, many concerns when I first fired up 5.7 but most of what I was concerned about has been mentioned already and it's good to hear that the core team is listening.

My biggest concern is that I think we need to pick a single way to get things done and try to implement that throughout the interface. It used to be clicking and then it was hover plus clicking and now it's getting to be a mish-mash of hover, click and drag. The same interface should behave the same whether it was invoked through the "+" on the toolbar or the 'Add Block' in an area. Please try to stick with one method and tweak it until it's perfect.

Franz, the Google Docs reference you made to a 'clean sheet' is exactly our point. They at least show an area labelled 'Untitled document' to give a clue that it's there. They don't just have a blank sheet where you have to wander around with your mouse to find the empty mystery boxes. Often in C5 there are editable areas with nothing in them which are impossible to find unless you already know where they are or wander around with your mouse. If the dotted borders were causing positioning problems, perhaps just shading without a border would work. I would also like the area name to be present whenever the area is highlighted so users know it's there. Again, you shouldn't have to wander aimlessly around to find stuff. As I play with it now, it's like the lights are turned off and I'm groping for stuff in the dark.

What's the point in reducing the size of the main toolbar icons but leaving the toolbar the same size? I'm 56 and believe me when I tell you that the icons are getting harder and harder to decifer as you make them smaller and smaller and I get older and older (and the rest of you are not far behind me!) The icon sizes on most modern interfaces are not getting smaller so why are we.

I'm a big fan of making the dashboard more useful rather than making it smaller and less intuitive. I mocked up an interface a while back but then lost the jpg. Basically it was a tabbed interface much like our tabbed block editing interface with tabs for 'Favorites','Full Dashboard','System and Settings','Extend Functionality'. This dashboard stayed pinned in the top right corner but expanded depending on the tab's content. I know there can be a speed issue when rendering large menus like this but it could be cached because the dashboard rarely changes unless a package adds stuff to it. In this case the cache could be blown out and rebuilt upon successfully installing the dashboard single page.

I'm strongly in favour of adding the internal concrete functions to the Redactor drop-downs. The Redactor's 'link' icon should have 'Link to Page', 'Link to File', etc included and the image should have 'External Link' and 'From File Manager' built in. It should look like our editor, not an editor we added stuff on top of.

Does the image editor work because I get nothing useful at the moment.

Is anyone else having problems with certain keys not showing up in Redactor in Chrome? The 'e' doesn't respond at all and there are several other keys that act like hot-keys that send Chrome to far away places. Should I look to a possible conflict with an extension I have installed on my Chrome?

The Composer is a function that I never used because setting it all up was so unintuitive and I never wanted to have to explain it all to a client. Perhaps if this is refined, it will make more sense. Just one point, when adding a new page I thinks it's really important to show the icons for the page types rather than just picking them from a drop-down. It's all nice and simple when the only page types are 'Full', 'Left Sidebar' and 'Right Sidebar' but I have lots of sites with very specific layouts and a picture is the only way to make sure the client picks the proper one.

All in all I'm excited because I know this is just a developer's release and I'm really, really glad to see the last of tinyMCE and the old layouts architecture!

I'm sure it will all work out as it has in the past (except for that ugly Scrapbook incident ;-)) if we all keep talking and respecting each other's legitimate perspective.

Regarding the cancel button "confirm" message: implementing a confirmation pop-up is smart but also allow for a modified click (holding shift or something) to react instantly for advanced users to be more efficient.

Love the UI and the new Automated Jobs is very cool. Ollie: my sitemap tree expands and has a new look.

Just so I'm clear - is this an "alpha" release? I'm totally interested in earning the "alpha tester" badge! :D

QUESTION: Will it be possible to have a custom template for the "gathering" feature (as well as some of the other new features)?

Yes - for the while block, the overlay template for an individual tile and the actual in page tile template

Sent from my iPhone

Here are some of my thoughts I've had while giving it a test run. Excuse any typos, points that have been covered extensively by others or rambly bits as I'm enjoying an IPA while I type this!

- Overall it's really exciting, I love the whole 'clean' feel to this version and I'm really looking forward to seeing what can be done with the Gathering block. The improvements to layouts is also very impressive, and I'm really excited to think that it'll be able to be configured to work with a CSS framework - i'd say it's a killer feature that other CMS systems simply won't be able to provide. To quote Franz - woot!

- I'd never call myself an interface expert but I do find myself regularly writing up instructions for clients on how to do tasks or training people over the phone. In both cases I find myself referring to textual labels to help describe tasks. Phrases like 'Click on Add to Main', or 'hover over the button than says Edit and click Properties' are much easier to understand than 'hover on the button that looks like a little gear..', or 'mouse over the page around the area where you already have some content until a small arrow and the word Main appears'. Something like the instruction 'Click on the Dashboard button' is intuative in 5.6 for a new user, but in 5.7 I'd need to say 'click on the icon on the toolbar with four squares'. I think these cues have been lost.

- I really admire and agree that it's important to have lean, minimal interface, but I think falling back to just icons is unnecessary, especially when there is plenty of space to add in a small text label. Regular computer users and those that are familar with concrete5 might see the meaning behind the icons, but I'd say that a new user is going to find that difficult. Many applications that have toolbars with icons allow you to configure it to just show an icons, but default to showing both text and icon initially - it's effectively suggesting that you need to learn the meaning of the icon first, THEN you can make the toolbar smaller if you want. On OSX, preference panels and System Preference both feature interfaces with strong icons, but still have small text labels for example.

- The plus icons for adding new blocks is a really useful addition, but again I think the icon alone is not sufficient to communicate meaning. A plus could be 'Add New Page' as much as 'Add Block'. A person familar with concrete5 will expect a dashboard icon to the right on the toolbar, but for somone who's never used it before, could quite easily see a picture of 'blocks' and go, 'oh, I was told I want to add a block, I need to look for a picture of some blocks'.

- The right curvey arrow used next to each area name doesn't really make sense in my mind, I would say it should be more of a configuration icon.

- Like many I'm just not convinced that removing the highlighting and 'Add to' controls from editable areas (without hovering) is a good idea. I've heard the point about it being tricky as the dashed borders add 2 pixels of extra spacing and can muck up layouts, but surely that's still better than hiding everything. I tried editing a 5.6 site on a Nexus tablet the other day, I was quite pleased to find it worked reasonably well. With this 5.7 preview, on a tablet how would I know where to tap? I even found just on my desktop that I was not sure where to click and was missing areas.

- Once thing I really like in 5.6 and 5.5 is how it has different colours for normal blocks (red), stacks (black), and copied blocks (a pink). I'm not seeing these in this version, I'm hoping that's just missing for now.

- I strongly feely that the little c5 icon on the redactor toolbar is not a clear icon for editing commands. It can't be just decorative on the main editing bar AND then used on the redactor toolbar for an action, that conflicts. When I first checked out the new editor I simply thought those features were still being developed missing.
Perhaps I'd rather see the default add link and add image icons turned into drop downs, with the options 'Add Link to Page', 'Add link to file, 'Add link manually' and 'Add image from File Manger', 'Add image from web' respectively. I'm excited about the Add Page name/username concepts though, very cool.

- I think I do agree with making the additional of new pages follow the composer style, it's always felt a bit strange to say 'navigate to the page you want to add a page under to first' (and I love the composer). My only concern with this is that we then lose the icons for the page types. I think these are an important visual cue to suggest what you will end up with.

- I'm lucky in that I've got great eyesight, but I'm finding the text on the dashboard drop down too small. The grey on the white for the Recent links, at that size is really not accessible. I have some clients that are much older as well as some with a range of disabilities.

- Why can't I pin dashboard icons to that dashboard dropdowns, please tell that hasn't been removed, it was an awesome feature! :-)

- When using the + button on the toolbar to add a new block, the concept of dragging the block onto the page is awesome. I do think though that the drag needs to be started with a click however, not an actual drag. In that dialog I can roll over the icon for each block type and it changes colour, with the mouse pointer changing. I'd suggest that a novice user isn't going to recognise the four arrowed mouse pointer as an indication to drag, where as something changing colour is an invitation to single click (fits with the understanding of a basic hyperlink). If the drag has to stay, I'd want a message on that dialog saying 'Start dragging the block you wish to add'. A drag on a touch screen is perhaps problematic at this point.

That's my bit of feedback for a Sunday night!

I know this doesn't belong here but I'm going to mention it anyways:

Feature Request: A single button that copies a core theme into [root]/themes

Newcomers start out using a core theme and then we tell them in the forums that this is bad. Suddenly 'Grandma' hits a knowledge gap. I wonder how many folks abandon their site because it all gets very complicated very fast.

The dashboard is broken in many ways at this point. we're not getting rid of pinning stuff, I think that functionality is just currently busted.

I for one like the new look and feel that is being promised. It is clean and from watching the video I do not see where there will be much shift in the learning curve.

These things may change over time once people start using it, but I personally love the work that is done by you guys and look forward to seeing this release.

I am especially interested in the authentication support and would like to know how I can contribute to it.
Is there any documentation available for that section as yet, or do I just jump in?

What is the procedure for reporting any bugs/issues found in the 5.7 devel code?

(The user icon -> account at the top right of the dashboard bar is giving me a 404 error)

First impressions are similar to others. I like the overall way the edit interface works.

1. In edit mode I would like some visual indicator of where I can edit before I hover the cursor over it.

2. Icons without names are hostile to all users and especially hostile to new users. Similarly for the dashboard, new users learn by browsing menus, not by guessing into a search field. The only exception should be a few icons that are common across all desktop and other web apps, like ....

3. I like the drag/drop moving of blocks, the top right icon and cursor. The visual metaphor is sufficiently common that what is now in 5.7 is fine by me.

4. Where there are names by icons, some of the text is a bit too small.

5. I liked adding pages from the page they need to appear under. That was wonderfully intuitive to me. 'Composer only' for adding new pages is a big step backwards towards Joomla and Drupal and throws away one of c5's big USPs. I want to see the new page I am working on in the context of a theme, not in the dashboard.

6. Composer should at least give the page the whole add process (mess) was triggered from as a default, rather than having to start from the top of the sitemap.

7. The add block popup with drag to place is good, but having it in the middle of the page is an inconvenience and it would be better as a bar across the top or down the side or as a pull down from the '+' icon.

8. When I copy and paste a block, I would like to be able to paste it anywhere by dragging from the '+' dialog.

9. I would like to be able to insert a stack by dragging from the '+' dialog.

10. I would like to be able to create addons that extend the '+' dialog and drag to the page to associate with a block or area. I see it as a visual metaphor that is ripe for adding all sorts of things (drag from a palette of pre-defined or favourite styles from the '+' dialog to a block)

11. Unlike many, I am not especially concerned about tablet/phone compatibility for all the edit and dashboard interfaces. Lots of visitors will view a site from a tablet or phone, post comments, send pms and other social stuff. But big edits and site admin doesn't need to be from anything but a real computer. However, wherever possible it may as well work from anything, which means having a consistent alternative to hover behaviour across all interfaces.

12. As some must be getting tired of hearing, I want to be able to control block caching to at least the level of granularity you can currently control full page caching. As more in-browser functionality gets added to blocks and especially to third party templates for blocks, having an all or nothing block cache will become a bigger and bigger issue. So why not address that issue now and save us all (including yourselves) a lot more grief in the future.

13. In the content editor, I would like a single link creating interface that then chooses between page, file or url. Same for images. Having separate interfaces depending on whether it is a c5 page or a URL or a file has always been a bit of a kludge. It feels even more kludge when seen in the slickness of the overall 5.7 edit interface.

14. As developers, how do we decide which categories our blocks appear under in the '+' popup?

I will no doubt have more thoughts as I continue to play. Overall, I like it a lot.

Two more points from my side...

1) Performance.
At the current state, this version is again very slow, backend as well as frontend. I hope that a decrease of performance is not the price to be paid for all the recent changes. Version 5.6.1 has been a huge step forward... I pray that the final 5.7 will perform as well as the current stable version.

2) Another thought.
A CMS is not a lifestye product. As an efficient, solid, reliable tool, it should act like a mature, experienced person, therefore it should be a bit conservative, particularly as regards changes of the UI.

Concrete5, in contrast, behaves like a teenager. It's exciting to watch - but one never knows what comes next, which is not ideal to work with.

Awesome work Franz, Andrew and the rest of the core team!

Things look to be coming along nicely :)

Quick question about the new layouts.

Is the ability to add "rows" no longer going to be possible?

I've been playing around with the new Composer paradigm and I have to say that it's now a completely 'out of context' editing experience. I have several page types. Some with only 2 areas and one with 10 areas. In setting up Composer, I need to tell it what type of content I need the user to fill out. Clearly if the page has 2 areas then I only need to tell Composer that I need 2 things for the user to fill in. If the page has 10 areas, I need to tell Composer about the 10 things I need the user to fill in. In the 'Output' section, I map specific content blocks to specific areas on the page. The problem comes when I go to add a page and Composer displays all 10 of the blocks for the client to fill in even though I have chosen a page type with only 2 areas to fill in. Does this mean I'm going to have to create a separate Composer page for each page type and then map the fields accordingly. I hope this is part of the interface that's not working yet.

It seems like such a duplication of effort. Newcomers already have to wrap their heads around the notion of a 'page type' and now we have Composer fields mapping to page type fields. This is supposed to be simpler? None of my clients would be able to set up a new Composer page on their own. Heck, you still have to tell Composer what 'target page' you want it to go under so the idea that you are somehow freeing the client from this 'conceptual nightmare' is false.

I think Composer actually stunts creativity because content has been reduced to just cold inputs. I have no idea what the page looks like while I'm adding it. It is completely out-of-context. I have no idea how the content I am adding is going to look in-context. I have no idea if the font is too large or if it would look better with an H3 or H2 relative to other elements on the page. Have you tested this new Composer concept with newcomers? I predict what's going to end up happening is that the client will fill in all the boxes and then immediately have to re-edit the page because it's not going to look the way they intended it to look. The competitive advantage for concrete5 is in-context editing. Why are we moving away from that?

Composer will allow me to set it up for page types that are not in the currently active theme. I activated 2 themes and now C5 thinks I have page types for both themes. This has been a problem since I started using C5 but I was hoping at some point the system would be smart enough to only recognize page types files that actually exist instead of silently failing over to 'default.php'. Clients don't understand the concepts surrounding page type files and when they try to create a new page type on there own, it's an instant support call because C5 is using default.php.

I think forcing users away from in-context editing and into Composer is a significant step backwards reminiscent of Joomla. Clients love C5 because it's intuitive. IMHO, this is far from intuitive. Please give the clients a choice between adding a page from the parent OR using the Composer for more structured, repetitive page additions.

Also, to add to this, the underlying problem the core team is trying to solve could be solved much easier than what is proposed.

I've also seen it very odd to ask the clients to "go to the page where they want the new page to go" as the hierarchical structure is not that clear quite often. E.g. they might go into a sub-page of "news" and say there "well, I'm under news, so I can add a new news article here". This THE case is where composer is at its best, i.e. publishing that does not require you to think about the layout but requires you to focus on the CONTENT (news, blogs, and other pre-set page concepts).

Actually, when composer came into existence in c5, I tried to use it for too many cases in order to "prevent clients messing with the layout". While it works for some cases, I've quickly learnt that the in-context alternative suits quite much better for many cases, even news on some occasions. That's why I now sometimes create a package that handles the page move for specified page type(s) e.g. in the mentioned news case (so that you can also add a new news article no matter where you add it in the first place).

So, my suggestion for the underlying problem: Why wouldn't you just create the similar selection for normal page publishing than what composer already has? That means, the ability to define where the new page goes when publishing it. This way, when publishing a specific type of page, the system would the same way (as composer does) ask the user where they want to publish the page OR publish it right away to the correct location if it has been set for the page type. One option that could be selected for the page type could also be "under the page where the new page is created", so it would also serve those who are used to the current concept. I don't remember if these have already been suggested here (too much text to search for...)

I agree that it's not always intuitive to go to the correct location first to add the page to but it is VERY intuitive to be able to click "New Page" and start editing it right away. In fact, I think it would be much more intuitive to ask where the page goes when you're actually clicking the "Publish" button for the first time for that page, quite what composer already does.

I like @mainio's suggestion about asking where it goes when publishing a new page. If they just see the current parent selected in the sitemap at this stage it should be enough to clear up the 'publish under what should have been a sibling' mistake. All solved without the abstract dashboard experience of composer.

Why do I feel like using concrete5 for the very first time?

I want to create a new page. I have to hover an icon that shows a pencil. Why actually a pencil, when i not want to edit, but want to add a page? Ok, in the submenu, i click "New page". A window pops up, called Composer.

It asks me "What would you like to write?".
Hm. Write a page? What does that mean? Shouldn't it be "add a page"? Maybe it's because English is not my mother tongue, but i think i would rather "write" an article, a poem, a novel, a book, but not a page. In this case, i just want to add a page, to put content into given areas afterwards. Maybe it's just the language. While i found composer previously not easy to understand, now it has turned into a total miracle.

Now i click on "Page", another window pops up and i'm asked to fill in the basics, such as name, description. Then i have to choose a page as "Publish target" which doesn't work, subpages do not expand in tree view, pages cannot be chosen, while - strangely - they can be moved around. Again i have a problem understanding that terminology: what is a "publish target"? Does that maybe mean "parent page"?

Beneath "Basics" i find a section named "Content", and i have no clue what content should go there? What does content of a page mean in the context of simply creating a new page? Which content? Which area? Where do the blocks go to?

Finally, because choosing a page as "publish target" doesn't work and the whole thing cannot be saved, i close that window, while i'm wondering how some people were able to test how to add a page anyway...?

Going to the dashboard, i find the Sitemap doesn't work either, it doesn't expand, no context. Ok, it's an alpha.

Then, out of curiosity, i hover the pencil icon again, there's a link named "Drafts". Amazingly, here i find a list of titles of the pages i just tried to add, but couldn't be saved, and when i click on one of them, the same window as before opens, asks me to fill in the basics etc....

I have to add, i am not new to concrete5, i have worked with it for some clients and i really loved the concept, the handling, and since 5.6.1 even i liked the performance. With 5.7 i'm totally confused. I don't know what should work / will work in the final version, but even performing the simpliest tasks brings up questions now. My overall impression is, that things became unintuitive and confusing. Most comments here reflect that.

Another big, if not the biggest drawback for me, because it has been an issue for such a long time and finally was solved, is the significant decrease of performance that can be experienced with that version.

Sorry to say, but this draft of the upcoming version is an example how fast good things can be screwed up by that current phenomenon what i call update-mania. It seems that developpers are easily getting bored with what they create. But it's an illusion that things are constantly, automatically getting better by notoriously getting updated. That's the obsession of our time, not only within the scope of software development, but it's to be found almost everywhere.

Here's some feedback (mostly repeating what others have said):

Front-end UI:
- Lack of labels is making editing experience kind of unintuitive. In the earlier versions you could easily see what all the actions do, but now it's more like guessing before you actually memorize what everything does. I'm pretty sure new clients will find the new version much harder than the old one. As someone said, the plus-button doesn't give any clue if it's for adding pages, blocks or something else.

- Lack of area indicators on blank page results in kind of a confusing situation. If the Core team does not make them visible, I'm 99% sure some add-on developer will :)


Dashboard:
- Some bugs here and there, not much to see and test. I have 3 concerns about the dashboard:
1) The feeling of "homelessness". Yes, there is the nice Full Dashboard view, but after you actually open a page there, you have no idea where you are, unless you click the arrow menu icon. Especially when performing an action redirects you to another page. A breadcrumb or something would make browsing the dashboard much more convenient.
2) Because of above, some add-ons are also losing some of their usability. For example in eCommerce, if you want to go from products page to orders page, you actually have to leave the eCommerce and find the orders page in full dashboard view. You can get around the problem with favorites, but I'd like see more sensible dashboard navigation out-of-the-box.
3) The only way I could get to System and Settings was going to the Full Dashboard view first. You can't access S&S main page through search either(?).


Performance:
Not quite as fast as 5.6, but nothing to complain about (considering it's an pre-pre-pre-alpha release). Would like to see the better cache control JohnTheFish is making noise about. At least package controllers should have variables stating if the package can be cached or not, just like blocks (of course it's not just simple as that). There's no sense using events if you're not sure if they are
firing or not.

Publishing pages and Composer:
Few messages above Mainio gave good suggestion on how to deal with Composer. I wonder if the add page dialog would first ask if the user wants to add a blank page or use composer templates and then proceed to either asking the publish location and page type OR going to Composer type selection. Anyway I agree it is a challenging topic to have the best of in-context editing and Composer-like publishing in the same "package".

I agree with most of the comments which have been said above. Especially the issues that Mainio, RadiantWeb and mhawke have brought up.

We are all experienced users with concrete5 so we have an idea of how stuff should work. One of the biggest benefits of using concrete5 has been that it is so easy to teach people to use. For example the red markers around stuff you can edit are so self explanatory that usually people understand them without me having to explain the idea to them.

I think the changes planned now are taking away some of the intuitiveness and ease of use that has been so wonderful about concrete5.

Just a thought, is there any planning to extend SEO in the 5.7 version. I'm not an SEO expert but know why it is very much important now-a-days.
As like WordPress, shall we have an option to set whether we want to publish my website on Google. Also it will be good if we have some advanced inbuilt features for SEO. I know that the meta families are there under attributes but need other features of SEO with that as an enhancement.

Anyway the new version looks absolutely awesome. Doesn't get a chance to take a deep look into the features but overall its awesome as like previous updates.

Rony

Just reading the comments here makes me worry, the loss of visual cues for editable areas, but especially this: "I think forcing users away from in-context editing and into Composer is a significant step backwards reminiscent of Joomla. Clients love C5 because it's intuitive. IMHO, this is far from intuitive. Please give the clients a choice between adding a page from the parent OR using the Composer for more structured, repetitive page additions."

My clients do not use Composer. I do not use Composer. My clients are often elderly with little tech skill. The in-context nature of C5 is what allows them to be able to use a CMS. I do not want to have to re-train all of them. Neither they nor I can afford it. Please do not degrade C5's biggest selling point, its usability.

Thanks.

Love that twitter and facebook will be built in, I hope that the inner workings will remain the same as we're using a custom SSO solution (e.g. please don't break it!)

Thanks Franz, Andrew and the team for constantly improving C5. It's great to see the back of TinyMCE and to see proper in-context editing with Redactor.

I would like to add a +1 for retaining highlighting of editable areas.

Currently I add a few CSS overrides in my 5.6 theme style sheets to change the borders added in edit mode to CSS outlines which don't add to an element's dimensions. The result is that layouts are not messed up when in edit mode.

I'm also unsure about the composer being the only add page method. I have never used it previously and while it might make sense when clients are adding pages it seems disjointed and unnecessary when a developer simply want to add a bunch of pages without content.
I see where your going but agree with the comments about choosing a pages location when adding it rather than navigating to it's parent.

I think Redactor looks like a good choice as it clean and fast.

I would be interested to know how it handles HTML code and whether the HTML block will be replaced. I use a lot of HTML blocks as opposed to content blocks as TinyMCE used to strip a lot out of the HTML. I guess that's why you needed a separate HTML block.

I currently use an advanced HTML block I created using codemirror which gives me a much better HTML experience. Syntax and error highlighting, line-numbering and format retention etc.

On another note I like many others would like to see the designer content add-on integrated into the core so it's development continues as this block improves C5's functionality so much it has become essential in my day to day use.

Good work so far however, looking forward to seeing the improvements as they happen.

Outlines are definitely more resilient than borders, as are background tints, but I am not sure they would solve all page distortion issues.

Either still require a dom element to wrap the entirety of the block before a style can be applied to that block. For example, a content block may be a bunch of P elements without any containing DIV, and they may be wrapping round a floated image block. Can adding a wrapping element to such a block be done in a way that cannot, in itself, distort how the page looks?

Is it even realistic to create an edit overlay without wrapping a block in something to apply that overlay to?

There are also, by necessity, blocks that cannot render fully in edit mode, so have an edit mode marker.

I know I'm late to this, but outlines are in fact much better. I often change / override the border wrapping div to have no border, but an outline that looks the same.

It prevents the layout from breaking, while still allowing a visual cue. Outlines do not add to the width, so it doesn't push things in on tight layouts. True, it might cut off a couple of pixels on the edge, but that's a very small price to pay for keeping something from completely reformatting in edit mode.

re: designer content -- lots of updates coming soon, and I'm also working on a "Pro" version that does repeatable items. Email me at concrete@jordanlev.com if you want to be put on the announcement list for that. Also, email me if you have specific feature requests for the existing version (if that's what you mean when you say "so development continues").

-Jordan

I'm drinking some of the coolaide here. I won't harp on things everyone else has already ranted about except to say that I agree, the icons need some kind of textual clue as to what they do and there should be a visual difference in edit mode before the user hovers over things.
My primary source of feedback here is regarding composer. I think maybe we're thinking about composer in and of itself too much like some in-wordpress-dashboardy-thingy and not nearly enough like the in-context editing powerhouse that it should be if it's apart of the concrete5 core and an integral way to add a page.

I personally would like to see composer go more the way of an amalgam of the current page type "defaults" interface (the one that has a page layout where you can designate composer areas) and the page properties area. So that when the user clicks new page, like @Mainlo said: the user would be prompted to select what page the new page goes under as well as what page type it is, but then also show the layout of that page type as the editing interface.

Something like this:http://cl.ly/image/03473g2N0o3H...
Yes… I did fire up ye old pixelmator, but I'm a visual person and figured others might be as well.

What, if the page has a light green or light blue background color?

Then the hovering thing would be fubar too. It's currently a light green border.

Why not make it a configurable color: light site/dark site, specific color, whatever.

That's a nice idea!

Maybe sniff out the overall background with javascript and adjust the contrasting colour as suits.

Or (not so sure about this), apply a solid outline in one colour, then superimpose a dashed outline above it in another colour, with the result that we have an alternating dash and either one or other will always contrast. Do it heavy black and yellow and it could look like construction tape!

I think a dotted darker outline combined with a light background of the same color would do for most page designs.

I think that they're trying to move away from the dotted border. The current iteration has a solid border. I think just adding some type of shading to that, or at least showing the solid border without the user having to hover over it is good enough for me.

I thought of sniffing for the background color but you would need to dig down to find out what div was actually responsible for color and it's common for divs to have no background color at all. I can grab the color under the mouse but that will change as I move the mouse around in the div. That would also mean that each editable area would have it's own color which would be quite confusing I think.

I still say let the client/developer decide as a dashboard item.

I think that would be a pretty elegant solution. A default could be set at the core, but developers could override at the root level on a per theme basis.

Could this be done with regular CSS within the theme?

From playing around C5 applies the class `div.ccm-block-edit.ccm-menu-item-active` on hover. I'm guessing theme developers could override this style as required to ensure the colors work.

This would also allow the theme developer to choose appropriate colors when themes have areas with different background colors.

Having to modify the theme CSS just to make Concrete5 easier to work with seems illogical - the CMS should make the job easy in the first place.

The dashed outlines can cause some themes to look very poor when in edit mode, but that's firstly to do with the extra width the dashed border gives to areas, and secondly to do with the additional "Add to Area" bit below each editable area which adds to the height. People are complaining that in 5.7 it is hard to see which bits are editable without hunting around with the mouse, so why not just show the hover state of all of the editable areas as the default?

This is what i have been adding to my theme when working in 5.7

.ccm-block-cover{
-webkit-box-shadow: 0 0 1px #8B8B8B;
-moz-box-shadow: 0 0 1px #8B8B8B;
-o-box-shadow: 0 0 1px #8B8B8B;
box-shadow: 0 0 1px #8B8B8B;
}

That helps, I have been playing with margins on .editMode .row too. There is so much cool stuff going on in 5.7, but still dissapointed in the editing experience

if you use margins it will mess with the layout.

naa, it's only edit mode, if you add some vertical space it gets the area labels from being on top of the areas below them. It makes an empty page a lot easier to deal with

Throw the attached app.css file into your application/css folder and see if it helps. Make sure all your c5 caching is off so it finds your app.css override file.

The background shading on the areas looks nice.

I also tweaked a number of other colors to increase the contrast on the dark backgrounds and shrink the size of the icons in the 'Add' panel. I like it a lot more but beauty is in the eye of the beholder.

Just wondering, is the new code being developed in conjunction with unit tests?

I haven't tried the 5.7 version yet, but I'd like to say that users should be allowed to choose if the use the Composer feature. Personally I hate it, but can see why it would be useful for some people. Also, the markings around editable areas are absolutely essential. Having trained around a hundred people how to edit sites in Concrete5, they understand the concept of "outlined areas are editable". Losing this would be a mistake, as would losing the text labels on buttons!

The only annoying thing about the current "Add To Area" functionality is when you want to limit the number of blocks that can be added to it, and yet when a stack or block is added, the "Add To Area" option is still there but you can't add anything. I know the reasons for this, but I have to explain it to clients EVERY time I train them, and none of them find it logical.

There's also a few things I'd like to see added or improved upon in 5.7, if they haven't been included already:

1. Jordan's Designer Content add-on should be included by default. It's by far the most useful add-on available. Hats off to you Jordan, you've made Concrete5 a pleasure to work with.

2. The Form block needs a couple of additions. Firstly to allow files to be attached to the notification emails, and secondly to allow a form to be split over multiple pages/steps. Also, the default email template is pretty dull and could easily be made far prettier as standard.

3. The Auto-Nav block is good, but it'd be improved if there was a simpler way to use the existing functionality of the block, like adding the is_featured attribute and the attribute that allows you to link a main menu item to the first subpage. Maybe show those sort of things on an Advanced Options tab when adding/editing the block?

4. The 'List Files From Set' add-on should be included, as it seems odd not having that kind of functionality available by default. It's common to have a page of downloadable files on a site.

5. When managing users, Deactivated accounts do not display any differently to active accounts within the list of users. When you manage lots of users, this fast becomes a nightmare. It'd be a simple fix to colour code those users in red or light grey, or have a toggle to switch between viewing active/deactivated user accounts.

6. The 'Public Date/Time' field on a page should be split into two: one to be used to signify when the page was created (which is what it currently does), and another to determine when the page becomes 'live'. You'd assume Public Date/Time means when the page goes public, so this behaviour needs to be clarified. In my experience, I've only ever needed to use time delayed publication of pages, but this feature is a complete ball-ache to achieve and would be much easier to use that date.

Does core team have a plan to update Redactor before 5.7 release?
concrete5.7-wip branch uses Redactor v8.2.3 now, but this version has big problem with editing Japanese/Chinese/Korean characters. We have to type in alphabet first, then convert to Japanese or other characters. But in the convert process, the mouse cursor will lose (yeah this is weird). This mouse cursor problem is not occurring in typing English.
This bug is already fixed in recent version of Redactor, and more bugs are also fixed in Redacter v9.0.x.
So, I hope to concrete5 Redactor will be updated before 5.7 release.
Thanks

As far as mobile editing goes, I think it should really be focused on and thought out. I just found this article about Wordpress, and some of the stats are really interesting:

http://thenextweb.com/insider/2013/07/27/wordpress-now-powers-18-9-...
--------------------
Among its findings, he revealed that WordPress is primarily being used on the Web. 31 percent of users are using the platform on their iOS app, 30 percent on their Android phone, 18 percent on their Android tablet, and 12 percent through the desktop app.
--------------------

Only 12% on a desktop? That's pretty huge. If c5 stays desktop only, or is desktop-primary with only a few token tweaks to make it just barely work, that's going to be a killer in a few years.

It might be that these people are all using the mobile stuff just simply because all that they are doing is blogging, but there's also this:

--------------------
When asked what those surveyed use WordPress for, 69 percent specified they used it as a Content Management System (CMS), while 20 percent chose to implement it as a hybrid blog/CMS, 6 percent as a blog, and 7 percent for an app platform.
--------------------

We, as c5 developers, tend to look at WP as mostly a blog, with some CMS features tacked on. Yet the numbers seem to say that people are primarily using it as a CMS. So they're doing more than just updating a blog post or posting a photo while on mobile. Presumably, they're actually doing real editing.

I'm not saying that we need an app or anything, but it seems like mobile should be up towards the front of the queue when deciding what features to implement.

I agree, mobile editing experience is one of the most important things about the future of c5. I think, WP mobile apps are providing not enough editing experience now. We can't edit some WP site with mobile apps, especially the site has additional custom post type and custom fields added by some major plugins. This is a big problem for WP developers, but it is a chance for us. c5 is now changing the editor to mobile friendly Redactor, changing the UI to mobile first Bootstrap 3. So, I hope to core team is understand how important mobile is.

I wonder if it would be possible to take the tight composer integration a step further?

So there would be one interface to add/edit from mobile, and then one for the full site? Add on developers could define different views for each composer style. On page edit, if you are on mobile, you see that interface, but not the full edit screen?

I'm meaning mobile as phone there, I'm assuming that tablets would get _most_ of the same interface as the desktop, but making sure that the interface is 100% as functional.

Seems like that might be a way to start heading. Not sure if it needs to be in 5.7, or if it can kind of phase in later. Seems like phasing it in later might work, but you'd have to make sure that the way things are changed now is going to be compatible with that next step.

Hi,

when moving a block from one area to another makes it not clear where other areas are at the current page type, because when drag and dropping the block, available areas are not highlighted.

Greets

I have an idea for how the "add page with composer" feature could elegantly address peoples' UX concerns (which I agree with -- it's a very jarring experience in its current implementation) while also keeping the basic idea intact (which I also agree with -- it's a great idea in terms of architecture):

What if clicking "Add New Page" brought up the composer in a dialog over the page you're currently viewing (not sending you to the dashboard). The "Publish Target" field would default to "under current page" (thus keeping pre-5.7 functionality exactly the same by default), but you could choose a different page if you want to publish it elsewhere.
Even better, there could be a new page type setting so that specific page types could default to specific publish targets (for example, "News Item" page types could all be added under a top-level "News Index" page by default).

-Jordan

I'd agree with that Jordan, particularly the page types default for different parts of the site. Makes a lot of sense.

I'm still new to C5, but one thing I would love to see is an easy way to pull data from a database.

We have forms for entering data, but no easy user experience (block) for designing a data extract from MySQL. I guess this would be a big ask, but I think it would help differentiate C5 from some of the other CMS's and would open up new uses for the system.

All this open discussion is great - but it makes me realise just how difficult even small steps are to make!

Good luck with 5.7... I'll be with you all the way.

Not quite GUI stuff to define what the data is, but there are hooks in there to work with listing, searching, filtering data. Check out this tutorial that I wrote:

http://www.werstnet.com/blog/using-custom-objects-and-lists-to-crea...

Does that kind of get to what you are wanting?

ProForms has a list/data display of form entries as an fyi:http://vimeo.com/70573874

ChadStrat

Thanks hereNT and ChadStreet.

Both solutions cover different angles really well.

As a C5 novice it would be great to have something like ProForms baked into the core, but I realise that keeping the core "lean and mean" and using add-ons may be preferable.

Thanks again.