ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
new design with 263-new-layout-ready (Feature #692)
| Status: | Closed | Start date: | 2011-11-10 |
|---|---|---|---|
| Priority: | Normal | Due date: | |
| Assignee: |  Eric Davis |
% Done: | 0% |
| Category: | User interface | ||
| Target version: | 3.0.0 | ||
| Remote issue URL: | Affected version: |
Description
The last 3 days I was working on a rebase which combines our current design changes, the changes from #263 (edavis10/263-new-layout-ready) and the current core chili 2.4.0.
The edavis10/263-layout-ready branch deleted the common.js and moved the content to application.js. Due to this change and the following changes on application.js it was impossible to rebase automatically. I had to rebase manually, identifying the changes in common.js and moving them, one by one, into application.js.
Since this was very error-prone I had to do it five times - this at least made it easier every single time and I believe the current version should be a working one for all of us. The solution now has a linear development history making it much easier to understand/read the changes committed.
I rebased on current unstable and created a pull request.
In comparison to unstable, the commit contains the following new features:
- login pulldown
- MyName menu (containing MyAccount / Sign Out)
- project autocompleter (using chosen)
- new navigation bar
- project navigation bar with submenus
- new logo
- breadcrumb bar
- overall design changes
- color
- fonts
- widget boxes
Related issues
| related to Feature #263: New layout | Closed | 2011-03-06 |
Associated revisions
[#692] change project navigation arrow on hover
- fix project navigation arrows
[#692] login slidedown implemented with tabindex and focus fix
[#692] images for new design
[#692] Main design changes for new theme
[#692] enable jump to project box to take options (projects and html)
[#692] fixes IE7 overflow bug in project search results
[#692] renamed div#account to div#header cleanup
[#692] removes div#admin-menu - now content of main menu
[#692] fixes admin-menu
new design on ticket view
filter / options / attachments fieldset redesign
[#692] header-menu subentries closer together
2 columns instead of 3 for issue detail
[#692] remove duplicate header from the bottom of the ticket show view
[#692] implemented widget design for mypage
- background gradient image missing
- made icon grey in order to keep it visible
- raised icon margin to position it directly inside the
widget when in personalize mode
- added a background image to display the gradient
[#692] Fix syntax errors and undefined methods in layout from merge
[#692] Update CSS by reviewing pre and post-merge diff
[#692] Fix failing test due to design changes
[#692] Cleanup layout structure from rebase
[#692] Fix and simplify the top menu open/closing
- Remove bunch of extra code from choosen
- Fix awkward indention
- Add admin menu items to the Modules menu
- Turn off bold on menu item hover, was causing jumping in width
- Fix color on opened top menus
- Fix a bunch of edge cases in the menu clicks.
- Remove gross 'html' binding in favor of a one time only one
[#692] Add register link back into the top menu
[#692] Use text based logo
[#692] Remove selected gradient from context menu tables
[#692] Fix the context menu styles
It was conflicting with S&P theme styles due to the CSS load order,
reset them back to the pre-S&P theme style.
[#692] Fix issue history styles
[#692] Fix image names
[#692] Add missing closing tag
[#692] Make breadcrumbs larger and not completely underlined
[#692] Use i18n label for the More menu
[#692] Add some style to issue action menus
[#692] i18n English string in view
[#692] Update the style of the issue show page to be cleaner
History
Updated by Romano Licker at 2011-11-10 04:44 pm
Working on it right now. We will post the pull request tomorrow.
Updated by Eric Davis at 2011-11-10 05:47 pm
Romano Licker wrote:
The last 3 days I was working on a rebase which combines our current design changes, the changes from #263 (
edavis10/263-new-layout-ready) and the current core chili 2.4.0.
Make sure you are targeting 3.0.0 (unstable) and not 2.x (master).
Updated by Romano Licker at 2011-11-11 12:58 pm
This is it - finally :)
Since we ran into more problems rebasing against current unstable, we decided to merge.
Comparatively it is quite manageable than anything else.
Updated by Holger Just at 2011-11-11 01:09 pm
Yay, finally! This is a huge step forward into the us having the next awesome design.
We have spend way more time than initially planned to bring the patches to the current unstable branch. I think we have to reduce that time for future patches, let's talk at the next team meeting what went wrong and how we can improve our process and communication. The merges and rebase attempts were a serious PITA and I wouldn't want to do something like this again (and don't wish that anyone else too).
So here's my plan for review. I think we are now beyond the point that many of the changes in the pull can be changed inplace. So I propose we review it and do any required changes on top of the unchanged pull. So any found changes should be handled in additional issues and be implemented separately. That way we can move to a simpler and more structured approach again.
Updated by Eric Davis at 2011-11-11 07:35 pm
Romano Licker wrote:
Since we ran into more problems rebasing against current unstable, we decided to merge.
Thanks for updating this. Merging it like this is going to make it hard to review. (below)
Holger Just wrote:
We have spend way more time than initially planned to bring the patches to the current unstable branch.
I think we have to reduce that time for future patches, let's talk at the next team meeting what went wrong and how we can improve our process and communication. The merges and rebase attempts were a serious PITA and I wouldn't want to do something like this again (and don't wish that anyone else too).
This is off-topic for this issue and given that this issue is going to have a complex discussion, I've moved this to the forum.
So here's my plan for review. I think we are now beyond the point that many of the changes in the pull can be changed inplace. So I propose we review it and do any required changes on top of the unchanged pull. So any found changes should be handled in additional issues and be implemented separately. That way we can move to a simpler and more structured approach again.
-1 Looking at the commits I'm going to say no. I see several commits that duplicate existing commits (91214e195f0929f5), some commits in German (I think), and a few reverting previous code. The history of this branch is extremely confusing at this point, will be difficult to review, and will hurt the code history.
If someone isn't willing to do a rebase of this on top of unstable, could someone do an internal rebase at least? Where only the commits in the branch are rebased in order to:
- remove the code and the reverting commits (e.g. commits: A, B, C, revert B would become: A, C)
- translate and update the commit logs to be descriptive of why a commit is needed and not how or what a commit is
- squash related commits into one commit
Updated by Eric Davis at 2011-11-12 06:38 pm
I'm starting to rebase and squash this branch with Holger's and Felix's help. I'll post here when the code is ready for review.
- Assignee changed from Romano Licker to Eric Davis
Updated by Eric Davis at 2011-11-12 09:44 pm
I've been working on this in the pull request and adding comments to it as I go. Basically I'm taking Romano's pull request, rebasing it onto unstable to remove the merge commits, and doing a squash rebase to consolidate the 83 commits into logical chunks that can be committed.
Updated by Eric Davis at 2011-11-13 12:36 am
I've just sent in a pull request with the results of my rebasing:
- fix unclear commit logs and add the issue prefixes
- remove merge commits from other branches
- reorder commits into logically sequence (see this gist for one version)
- squashing related commits into a single larger commit
- removing unnecessary reverts
I've also done a manual diff of the layout, application.css, and application.js to pull request 121 to make sure nothing major was missed.
Since there is so much here, lets try to keep the code review in this issue. We should review this like so:
- should each commit be included or not?
- for code changes as a whole, is each line acceptable (security, code standards, etc)
- does the changes make sense? Like is this a good change or should it be different.
Eric Davis
- Status changed from Open to Ready for review
Updated by Eric Davis at 2011-11-14 02:03 am
I started a wiki page (692_Layout) to track all of my feedback. The design review is complete and I'll work on the code and feature review next.
Feel free to add sections for your own reviews and then we can go over everything at once and decide how to proceed.
Updated by Felix Schäfer at 2011-11-14 06:22 am
Eric Davis wrote:
I started a wiki page (692_Layout) to track all of my feedback. The design review is complete and I'll work on the code and feature review next.
Feel free to add sections for your own reviews and then we can go over everything at once and decide how to proceed.
Wasn't sure how to add my comments to your feedback, I've added them as lower-level list points.
Updated by Romano Licker at 2011-11-14 04:07 pm
I fixed two minor bugs. One broke themes of ours.
Updated by Eric Davis at 2011-11-14 04:35 pm
Felix Schäfer wrote:
Wasn't sure how to add my comments to your feedback, I've added them as lower-level list points.
I guess that is fine. I was hoping everyone would review the design themselves adding their own comments (i.e. append only) and then as a group we would go through them and decide what to do.
Updated by Eric Davis at 2011-11-15 06:30 pm
I'm changing my mind; using the wiki page for discussion is becoming a mess. Lets keep all discussion of the features and bugs in this issue (or other issues if relevant) and only use the wiki page for listing what everyone has found.
Updated by Niels Lindenthal at 2011-11-15 07:43 pm
Eric Davis wrote:
I'm changing my mind; using the wiki page for discussion is becoming a mess. Lets keep all discussion of the features and bugs in this issue (or other issues if relevant) and only use the wiki page for listing what everyone has found.
What do you mean by that? Do you want to use the wiki to track issues?
Updated by Eric Davis at 2011-11-15 08:33 pm
Niels Lindenthal wrote:
Do you want to use the wiki to track issues?
That's close to what I meant. I intended the wiki page to be used as a record to collect each persons' feedback as they test the new code. Things like bugs, usability problems, or things that need to be changed. Then, as a group, we would review them all and decide what to do with each one in the issue (e.g. fix now, create issue and fix later, ignore, etc).
Recent edits to that page have been more about discussing the things already listed there (which is better done in this issue once everyone has done their review). This is making the page a mess and difficult to understand.
Roughly the steps are:
- People review the changes individually
- As a group, each thing is discussed and duplicates consolidated if multiple people found the same thing
- As a group, decisions made on what to do for each item
- Actions taken based on the decisions
(This is the same as how all proposed changes are done, though smaller changes move faster since there is less impact than a full redesign)
Updated by Felix Schäfer at 2011-11-27 06:15 pm
I've added my comments to the pull request and to the wiki page, not much more to add to Eric's points though.
Updated by Eric Davis at 2011-12-01 11:14 pm
Thanks Felix, I've reviewed your comments in the wiki and the pull request. At this point I think it's safe to close this issue for review since there have been almost 3 weeks.
I'm going to try to summarize the issues found and propose some decisions next.
Updated by Eric Davis at 2011-12-01 11:47 pm
Okay, I've gone through the notes on the wiki and the pull request and summarized everything.
On the top of the wiki (692_Layout) is the summary with my opinion of what each feature/part would fall under: blocks the release, would be nice to have but not required, or wait until later.
Does anyone have any feedback on:
- The "status" of each item? (e.g. blocker, later)
- The decision of each item?
You can add your feedback under the item with your name or discuss it here.
The sooner we can reach an agreement, the sooner I can update the pull request, and the soon we can finish this issue up (and get 3.0 released). Thinking 3-4 days to get final feedback should be enough time.
It's been a long feature but we're getting close to the end now.
Updated by Eric Davis at 2011-12-09 09:07 pm
I'm going to assume that silence on this issue means an agreement. Since this feature is blocking 3.0 and we are already dangerously close to missing our release dates I'm going to take some drastic actions:
- I've scheduled some time this weekend to work on this
- I'll be fixing the most critical problems with this code
- I'll be merging that code into unstable
- For things I am not able to fix, I'll be ripping out functionality with the explicit goal of getting this code into a working state (expect hacks, workarounds, and lots of cursing... ;) )
Once that is done then it will be time to finish or push back on the last 3.0 features and release a beta. Any and all bugs can then be handles post 3.0-beta or in minor releases (3.1.0, 3.2.0, etc).
Updated by Eric Davis at 2011-12-10 12:36 am
Did a lot of work on the blocker items, specifically around the projects menu. Will continue tomorrow, rebase, and commit.
- Status changed from Ready for review to Open
Updated by Eric Davis at 2011-12-10 07:02 pm
I've fixed all of the Blocker issues listed on the wiki page except for one that needs to be discussed first. I'm going to create an issue for that one and then either fix or create issues for the rest of the items.
Thanks to everyone who contributed code, designs, ideas, and helped with this new design. It will be a great step forward for ChiliProject and will make future usability improvements easier.
- Status changed from Open to Closed