I have a web application I want to build, how should I manage all my tasks with fogbugz.
If I want to list all the tasks I have on a page by page basis, should I use areas for that?
I also want to break it down to modules, again I use areas?
example:
Users
add user
delete user
assign permissions/roles to a user
or if it do in on a page basis the list would look different.
Over time I've found that it's a waste of effort trying to rigidly structure your cases by anything other than Project and responsibility (Area).
Just get the cases into FogBugz under the right project and area with a good title.
So, the Project is whatever the product or business project is that you're working on.
The areas should be things like UI, Code, Docs, Data Migration, the kinds of things that people have different responsibilities and/or abilities in.
Then title your cases for easy management and searching, keeping the scope of the case to a few hours if possible, certainly no more than a couple of days.
So, from your example it could be as simple as...
Add Role
View Role
Update Role
Delete Role?
List Roles
Add User
View User
Update User
Delete User
List Users
Add dependency checks to delete role.
To be honest, even the above is probably a little over-board, you'd probably get away with:
User Role add/view/update/delete/list
User add/view/update/delete/list
The simpler you make it, and more trust you put in your devs, the less hampered your devs will feel and more likely to just get on with it.
Users can filter by cases assigned to them, so they can always view their own queue.
Lots of different areas will just create unneeded complexity - you just don't need that level of breakdown.
Bear in mind that you should never have large numbers of active cases, and you don't need lots of categorisation for short lists.
I find that the best use of the area flag is to group work into a queue across more than one developer. Then you get a queue anyone can quickly view.
For instance you might have a "Product planning" area for feature ideas that you haven't decided to do yet. In a large team you might assign an area for each sub-team, so each line manager could view their queue on its own.
We have one large and complex project that's been using Fogbugz for 4 years and we've never needed more than 5 areas. If we'd split areas the way that you suggest here we would now have hundreds of them.
Related
I am designing an app that has three different user roles for example something like Enterprise, Small Business, Merchant but not those specifically and I went ahead and made separate storyboards and views for how each user would see their own pages and realized that I had no way to connect the three users. Overall there are certain areas of the app where each user would have identical pages, but they have similar layouts but their own particular design style. One of the users has read and write privileges on certain areas of the app where the other two would only be able to read.
I have had difficulty finding a suitable solution online, but if there is one could someone point me in the right direction, please? Otherwise is the appropriate solution to include each separate page for how each user would see it and connect them all in the main.storyboard file and then just hide the pages that shouldn't be seen? Would doing so clutter the storyboard space and slow things down when i go to run the simulator or when users are on their perspective sides in the app?
This question is purely conceptual, it does not include any code.
I am building an app with a single User model. I would like to give users the freedom to choose from 3 different site styles. These styles will affect other components of the UX, including a Message model and messages controller.
I am thinking the best way to go about this is to give each user a "style" column, and based on which site style they choose, either save the value as a string or an integer into the users table.
I have concocted a way to use the same Message model and messages controller, and the same actions inside the messages controller, for all three of the different types of users. Within each of the actions of my messages controller, I would basically start off by querying for which "style" attribute the current user has in their corresponding database row. Based on the three possible "styles", I could then use an if-else or a switch statement to complete the right thing inside of the controller action, depending on the current user's style, including rendering a "style"-specific template rather than the default view template.
Is there a better way to go about accomplishing this? Is it completely discouraged altogether? Am I better off just creating 3 different messages controllers, would that be more RoR conventional and less damaging to the performance of the app?
How catastrophic would it be for the performance of my app if I were to follow this approach with the actions of my messages controller and maybe even two more controllers?
Thanks in advance for any insight anyone can give me :)
I've done very similar things with little-to-no performance impact. As long as the changes are purely HTML/CSS/JavaScript this can be easily accomplished with a working knowledge of the Rails Asset Pipeline and a single column in the database. You'll end up hitting more if-statements in your views, but those handful of boolean expressions will have a negligible effect.
Just make very sure that your alternate view styles don't affect your Controller or the Models themselves (save any methods and validations pertaining to your new column in the User table).
Be sure to dish out unique scripts and stylesheets based upon which style the user has selected (it would be woefully inefficient to load a single stylesheet and dynamically change classes to use certain elements, for instance. Instead you'd want to choose which stylesheet to include based upon the user's selected style, and do the same for scripts).
If you have any specific questions about implementing this, feel free to inquire further. In the mean time this will prove to be an important read, if you are not already familiar with the material.
I am just starting a project and the wireframes are ready. But looking at the wireframes it seems that the primary goal was to reduce the number of pages and to include maximum functionality in to a single page.
Taking an example of an organization, the top portion of the page will show the organization details, below that at the left we have an division structure as a tree view, clicking on a division will populate the employee list on the right as a table, and when you click on an employee it will populate the employee details below.
Current wireframe looks something like this:
End user is happy as they can see the entire functionality on a single page and doesn't need to navigate to another page.
But this design reminds me the screen of some old desktop application and I feel that this page is unnecessarily complex- I want to split this in to multiple pages (at least in to three). Also, I am using MVC 4 and splitting this in to multiple pages will definitely help me to reduce the complexities during implementation.
But before arriving at any conclusion and raising any concern, I would like to know what you guys think. Some articles related to User experience are also welcome.
Here's what I think.
Whether the design above is 'right' depends on the target audience and the type of work / business process they need to carry out. There may be a strong business argument for being able to see all the information (org details, divisions, employees and employee details) on one page. It is not unusual to see a lot of information displayed in a page with a lot of interactivity - users expectations have increased because of consumer sites such as Gmail.
The users might find it frustrating if it was broken out into different pages.
To put it another way, I don't think there is a valid technical justification for making the designer change the UI above to split it into different pages.
You would be able to build the UI above in MVC as a single page web application. You will probably need to implement a lot of controller actions to support ajax calls. You're almost certainly going to end up using a lot of JQuery and you are probably also going to end up with a significant amount of JavaScript to write. Also, you'll need to make sure the designer has made good decisions around the sizing of the page. Is it going to be fixed width or dynamic for instance? You'll need to emit well structured HTML in order to achieve that solely using CSS (which I would strongly advise you do).
I am a little ashamed for asking so many questions, but I really want to learn.
In Sipke's blog a webshop is created. There is one specific question that boggles my mind when trying to do something similar.
Let me spell out the basic requirements:
User registration form and login, etc. This one is covered by the blog and it works nice.
Creating product parts and so on. This one is covered and no problem there.
Ordering by filling in an order form and making the payment. See down
Having the order page maintainable by customer. See down.
Viewing your own orders and their status. See down
Maintaining customers and orders from backend system. This one is covered by the blog and I need to do some work there yet.
As for items regarding creating orders and viewing your orders. I have followed the approach for creating records and using standard MVC controllers. But then I encountered problems:
Menu for orders page. This I had to do manually after installing the module.
The order page itself. I had to create the view including title and so on. But I can imagine a customer wanting the order page on another menu and with a different title. And maybe add even some own content to the ordering page. This I couldn't achieve by using standard MVC approach. So maybe I am using the wrong approach here. So I was thinking about using contentparts for creating an order and displaying them and using the drivers and handlers for that. But before I go down that road and refactor everything I want to know if that is the right approach. A downside could be that once the module follows that route it can then not so easily be reused with customers that have other cms's capable of hosting an MVC3 module.
So when to use drivers, handlers and contentparts and when to use standard controllers and views.
You should use Drivers and Parts (with Handlers if needed) when you want to create functionality for content items. E.g. if you want to display a custom media with all products, you could create a Part (together with its Driver, etc.) to handle that. Read the docs on Parts.
If the functionality is not tied to content items the most possibly you want to use the standard MVC toolbox, it's fine. Look at the built-in modules how they do that. E.g. the Blog module uses controllers and views to show the admin UI, but has parts to enhance the functionality of for example the Blog content type.
To make things more complicated you can employ ad-hoc content items to build a page that you'd normally do with simple views, but that's an advanced topic :-).
So I am new to programming and working in C# and learning MVC. I have finally undertaken my first personal project to put to practice what I have been learning from the books/tutorials I have been following. My project is your typical store that list products, has a shopping cart, user account, admin site...etc.
I have managed to wire up NHibernate to my MySQL DB, and posting records to a view.
My question is "where should I start?". It seems I could go a lot of different directions, Admin site to manage the site and products, getting the products showing on the site as I would like, User accounts. What is some advice of how I "should" tackle each component?
I leaning towards the admin site since logically putting products in the store comes before showing the products on your store.
Any advice is greatly appreciated.
I concur with #Tod
Pick a portion of the website that is needed and build it. Build up your model (include a viewmodel), then your controller, and finally your view.
In my case, I chose to start with Users.
I created my Database and Users Table (no I didn't use code first or EF)
Then I created the LINQ DBML file
Then I created as super simple repository that talks to the LINQ classes
Next I created a service layer that does a little more heavy lifting before communicating with the repository layer
Following that, I build a ViewModel that would "transform" data that was to be used in the view. This also included building some HtmlHelpers and Extension Methods.
Now to my controller. I build new ViewModel object, pass an object to the ViewModel, and then return the viewmodel to the view.
Lastly I implemented the View, did my CSS and Markup.
So when I visit the site, I don't see a whole lot except for a nice finished Users section. This also includes a sign-up area, login area, etc.
Now that the Users section is finished, my next big section is "Events" whereby I will start the process all over again.
Start with what you can use first. If you can't put products in the system, what good is "getting the products showing on the site as I would like". On the other hand, having a site where you can enter products may be (somewhat) useful on it's own.
Even though you are the client, ask yourself: what is the smallest piece of functionality you could build that would be useful for your client? Build that first!
Good luck! Enjoy programming!
I guess its a bit of a personal preference. For me, I'd rather work on the front end customer facing stuff first, ie: rending products, shopping cart, purchasing and checkout.
The admin side of things doesn't really add value to the product from a customer perspective. In a less than ideal situation you could release your store without an admin interface, and manage products directly in the database (not ideal), but you could still release it and sell products to the public.
The admin side doesn't add that kind of value, and even if you can add and remove products from the system, you still can't release the product as customers can't see or buy them.
I like to focus on what adds the most value first and build from there - in practice however this isn't always possible.
Either way though, I think taking it from which ever direction you're more comfortable with is the best approach. If logically you find it easier to conceptualize the process of ordering products when they've already been added to the system from an Admin panel, start at the admin panel.
If you find it easier to build an edit product page based on what you've determined you need to render on the public facing page, then start with product listing and build management around it.
The user account stuff is used throughout your site so you should create that first. The shopping cart is going to be associated with the user account.
Ok going by your question, in my opinion, you might want to find yourself a specific goal, like doing a website for someone that owns a business that you know (this is what I've done, and so have a couple friends of mine).
I've found that the more specific the aim, the better the coding experience. So if you're motivated to a particular project then you'll know what's necessary to do. Give yourself a project to do like a music library utility for example, and see where it takes you. :)